Chrome doesn't parse HTML in textboxes

Shifty Geezer

uber-Troll!
Moderator
Legend
Just trying Chrome instead of IE, and where generally faster it has one significant annoyance. As I type into this textbox, it doesn't have the sophistication of IE. I can't press ctrl-B for bold, for example. And if I do bold some text, or add a link, it's not WYSIWYG but html code, which looks a mess and can make things hard to read.

I went looking for some textbox extension to make textboxes WYSIWYG, but couldn't find anything. Is there any way to enable this in Chrome?
 
This will be entirely dependent on the sites you're visiting.

I.e., if the site uses a recent version of CKEditor for rich text control, it will work. On the current Beyond3D forum on the other hand, it will not. Although, I believe vBulletin have started supporting Chrome in their WYSIWYG-editor somewhere in the recent 4.1 line.
 
The rich text editor is JavaScript so Chrome should excel at it. There must be implementation issues if it doesn't work in Chrome.
 
Chrome DOES have very nice page zooming though. It does some kind of fairly sophisticated multitap filter on zoomed images, making them look very nice and smooth. Too bad though the only way I've been able to access page zooming is by holding CTRL and scrolling the mouse wheel. There seems to be no GUI widget for it, nor any right-click context menu option for it anywhere that I've been able to find.

I use chrome for odds-and-ends browsing, but IE is my main browser. Most of all because I've still not found a way to access my google-toolbar-for-IE bookmarks from within chrome.
 
It's shocking how these browsers miss pretty vital features. RTE doesn't work properly on Chrome for a lot of folks, it appears after some research, but Google haven't said or done anything about it. IE hasn't had inline or optional spellchecking in any version and IE9 doesn't improve on that. Talk about missing the basics. I despair! :rolleyes:
 
Supplying an RTE to websites really isn't Google's job. WebKit based browsers are, and have for the longest time been, perfectly capable of providing an editable canvas (one could whip up a basic HTML editor in a couple of minutes), but how to interact with these elements haven't really been completely standardized since the time when browsers started to implement such features.

Also, pre-Chrome on the desktop their market share probably wasn't big enough to bother with. Thus, web developers (who'd have to parse and sanitize the generated code from a rich text editable field, deal with lacking implementations or various (un)standardized functionality, etc.) originally focused on IE and then proceeded to modify their code to work with Firefox too.

Now, with HTML5 gaining some traction and Chrome becoming a browser to be reckoned with, many applications will probably have to entirely rewritten for broader cross platform compatibility. Some have been, others haven't yet or won't be.

Google can't really help with this (without implementing legacy/deprecated functionality and hooks into Chrome, something we shouldn't want), apart from providing documentation.
 
But as long as they don't support a valued feature, they won't be used, which is self-defeating, and the whole issue with evolutionary computer systems. We end up tied to badly designed system people have used and are familiar with and expect. In this case surely Google should provide a stop-gap solution such as an RTE plugin to help with the transition?

Also IE9 is proving buggy, so where I could just go on the internet, since trying Google and 'upgrading' IE, now I have to worry about what browser I'm going to use for what web pages.
 
What does RTE have to do with the browser? You can't just throw in an RTE field forced by your browser wherever there is a textarea. The page code itself has to provide the code and be able to parse and restrict the information provided in that field.

Now if a standard RTE like tinymce doesn't work in Chrome, then that's an issue that google would need to address and that's a problem with their javascript support.
 
It's shocking how these browsers miss pretty vital features. RTE doesn't work properly on Chrome for a lot of folks, it appears after some research, but Google haven't said or done anything about it. IE hasn't had inline or optional spellchecking in any version and IE9 doesn't improve on that. Talk about missing the basics. I despair! :rolleyes:

I've never noticed the difference! Now that you say it, I guess, but I've been using Chrome (and now also Chromium on Ubuntu) like forever. I actually don't need spellcheckers or wysiwig in my browser. That kind of thing is total overkill for forum posting. Of course, where it does matter like Google Docs I think it would be obvious that it is there no problem.

Also I wouldn't be surprised if they actually would work but that the forum software simply only turns it on for 'known' browsers that support to guarantee optimum compatibility with more obscure / slow mobile browser types.

That said, I am one of those that does remember which browser to use for what. Most remote access pages for instance work best with FireFox, while one version only seems to work well with IE (though it's probably just a security setting I didn't find) as well as our ancient and user un-friendly web-based time tracking software which just doesn't work at all with anything (it asks for IE6 !) . For everything else I use Chrome, except now recently on my laptop I'm having some issues with pages sometimes not loading that I can't seem to solve.

Great fun .. :p If FireFox 4 had a start-up tab with nice big icons for your frequently used pages like Chrome, Safari and now even Internet Explorer, then on my XP machine I'd probably use FireFox 99% of the time right now. On Ubuntu I keep using Chromium pretty much exclusively, and on my Windows 7 home PC I keep using Chrome, except the rare occasion I need to remote access for work on it.
 
I've never noticed the difference! Now that you say it, I guess, but I've been using Chrome (and now also Chromium on Ubuntu) like forever. I actually don't need spellcheckers or wysiwig in my browser. That kind of thing is total overkill for forum posting.
I disagree. Unless one is fluent in hypertext parsing, it's hard to see what's bolded, italicised, and most importantly web links can be an utter mess versus the cute blue text of IE's text entry. I prefer an inline spellchecker to pull up typos as I can't get on very well with this keyboard :p, and it's quite apparent a lot of posts on the internet could benefit. Also, whether it's overkill or not, a lot of what technology doesn't isn't necessary, but it's nicer with than without. And WYSIWYG input is definitely a valued nicety.

Also I wouldn't be surprised if they actually would work but that the forum software simply only turns it on for 'known' browsers that support to guarantee optimum compatibility with more obscure / slow mobile browser types.
I don't know what is responsible where for providing a decent text editor with hyperlink formatting, but it should jolly well be in place!
 
I disagree. Unless one is fluent in hypertext parsing, it's hard to see what's bolded, italicised, and most importantly web links can be an utter mess versus the cute blue text of IE's text entry.
Well, that's actually part of the problem. What an "editable" field in a browser is originally providing is exactly that. "Hypertext". And you'd expect the client to be fluent at hypertext parsing, right? Well, yes, indeed.

However, the server should be very wary of trusting such output. In a forum for instance (well, mostly anywhere), trusting the client is simply out of the question. Hence the need for several layers of parsing and browser specific (hi, IE) implementations in the past. Web-standards compliant alternatives are now available, but in the end it's still up to site operators to implement them.

Anyways. As a stopgap on B3D, you could try setting your preferences to the "Standard Editor". This will get you an editor hat won't make you remember any hypertext parsing (but you'll still have to see it) as it automatically inserts BB-code tags based on your GUI input. At worst you'll waste a couple of clicks hitting the "Preview" button.
 
Back
Top