5 ms·

Let me diverge for a moment: Everytime I see this, I wonder why browsers (and the W3C) don't add more functionality to textarea. ContentEditable always felt l

by pothibo 13y ago

Let me diverge for a moment: Everytime I see this, I wonder why browsers (and the W3C) don't add more functionality to textarea. ContentEditable always felt like an ugly hack for me. A rich set of API on textarea could move the web forward. Imagine building an IDE in a textarea. That should be possible. </rant> Great work nonetheless, very clean code and very nice documentation!

stronglikedan 13y ago
Maybe because it would break backwards compatibility (and possibly the spec) for the tab key?
- tghw 13y ago
  It wouldn't be hard to add that functionality. An attribute could specify whether tab blurs and focuses the next input or actually inserts a tab.
  - ssmoot 13y ago
    Accessibility seems like an issue then?
camus2 13y ago
remember XHTML2 ? XFORMs , yeah,it was a pain to write but FULLY EFFIN extendable ... so much that browser vendors did not want to implement these stuff and came back with hacks like web components and shadow dom making everything even more painfull to write and extend...So there was an opportunity,it was missed.
TazeTSchnitzel 13y ago
Related: Why isn't there a wrapping version of <input type=text>? For a single line of text which you wish to wrap, using a <textarea> with JS hooks to prevent pressing the return key is a terrible hack. Why can't you do <input type=text wordwrap>? Or <input type=text style="word-wrap: break-word;">? Also, in this day and age of sans-serif, variable-width fonts, why do we have to specify rows and cols on <textarea>?!
- danellis 13y ago
  Serifs are irrelevant, and browsers have had variable-width fonts since Mosaic, WorldWideWeb and ViolaWWW, so making textareas use a monospaced font and specifying their size like that seems to have been just laziness. If there was a good reason, I'd be interested to know it.
deleted 13y ago
[deleted]
grinich 13y ago
You should join the ietf and w3c mailing lists. Then you will understand why things don't move faster.
- 99percenter 13y ago
  Could you explain a little for the 99% who won't join those mailing lists?
  - grinich 13y ago
    Politics and ego over an asynchronous channel.
    - chadillac 13y ago
      What stops people from getting things done? People.
bowerbird 13y ago
first, good luck to the guardian on this endeavor! :+) second, i can't help observing that efforts to use contenteditable seem to start with a rush of success -- as the early results are always very impressive -- but then seem to quickly bog down in the particulars. bug-reports come in which are difficult to reproduce, typically originating from idiosyncrasies in an o.s., or a browser, or (in one thorny case) a _combination_. and although people have much enthusiasm for solving these glitches at first, the slog is generally endless, and, eventually, it wears down even the most determined. at least, that's what i have observed, enough so that -- once i started experiencing the bramblebushes too -- i pushed the contenteditable strategy off to the side. which was easy, since i've been a long-time supporter for light-markup. no, not markdown, since that thing is too primitive, and forked, and fragmented nowadays, and will give you a big dose of misery down the line. i built my own light-markup -- "zen markup language", extension .zml, based on the project gutenberg corpus. i have also built a phalanx of e-book authoring-tools over the last 20 years, and it's all come together now. the trick is making an editor that will be acceptable to both the light-markup adherents _and_ the wysiwyg folks, and i think i cracked that nut. i'd like your feedback on pre-release versions of some new stuff i'll have soon. e-mail me at bowerbird@aol.com if you'd like to play... and again, best of luck to the guardian people on this! -bowerbird
- derefr 13y ago
  That said, a plain contentEditable is just fine already if you can prevent the combinatoric explosion of browsers+OSes. Like, say, if you're shipping a node-webkit application.
snowwrestler 13y ago
I don't understand why companies and CMS projects think that everything needs to happen in the browser. Especially in situations like publishing, when the content creation is being done 100% by people under employment or contract. Give them a native app or browser plugin for authoring, and you can solve all these problems with much greater sophistication. In the distant past I used to use Microsoft Content Management Server to power websites. It lacked most of the modern features of a web CMS, but it provided a native app and IE plugin for authoring. In terms of code control and consistency it kicked the ass of even the best JS libraries available today. A native authoring app, side loaded onto employee machines, would be a much more powerful authoring solution. It would produce clean HTML code and push it into the CMS via an API call.

by pothibo 13y ago

stronglikedan 13y ago

Maybe because it would break backwards compatibility (and possibly the spec) for the tab key?

tghw 13y ago
It wouldn't be hard to add that functionality. An attribute could specify whether tab blurs and focuses the next input or actually inserts a tab.
- ssmoot 13y ago
  Accessibility seems like an issue then?

camus2 13y ago

remember XHTML2 ? XFORMs , yeah,it was a pain to write but FULLY EFFIN extendable ... so much that browser vendors did not want to implement these stuff and came back with hacks like web components and shadow dom making everything even more painfull to write and extend...So there was an opportunity,it was missed.

TazeTSchnitzel 13y ago

Related: Why isn't there a wrapping version of <input type=text>? For a single line of text which you wish to wrap, using a <textarea> with JS hooks to prevent pressing the return key is a terrible hack. Why can't you do <input type=text wordwrap>? Or <input type=text style="word-wrap: break-word;">? Also, in this day and age of sans-serif, variable-width fonts, why do we have to specify rows and cols on <textarea>?!

danellis 13y ago
Serifs are irrelevant, and browsers have had variable-width fonts since Mosaic, WorldWideWeb and ViolaWWW, so making textareas use a monospaced font and specifying their size like that seems to have been just laziness. If there was a good reason, I'd be interested to know it.

deleted 13y ago

[deleted]

grinich 13y ago

You should join the ietf and w3c mailing lists. Then you will understand why things don't move faster.

99percenter 13y ago
Could you explain a little for the 99% who won't join those mailing lists?
- grinich 13y ago
  Politics and ego over an asynchronous channel.
  - chadillac 13y ago
    What stops people from getting things done? People.

bowerbird 13y ago

first, good luck to the guardian on this endeavor! :+) second, i can't help observing that efforts to use contenteditable seem to start with a rush of success -- as the early results are always very impressive -- but then seem to quickly bog down in the particulars. bug-reports come in which are difficult to reproduce, typically originating from idiosyncrasies in an o.s., or a browser, or (in one thorny case) a _combination_. and although people have much enthusiasm for solving these glitches at first, the slog is generally endless, and, eventually, it wears down even the most determined. at least, that's what i have observed, enough so that -- once i started experiencing the bramblebushes too -- i pushed the contenteditable strategy off to the side. which was easy, since i've been a long-time supporter for light-markup. no, not markdown, since that thing is too primitive, and forked, and fragmented nowadays, and will give you a big dose of misery down the line. i built my own light-markup -- "zen markup language", extension .zml, based on the project gutenberg corpus. i have also built a phalanx of e-book authoring-tools over the last 20 years, and it's all come together now. the trick is making an editor that will be acceptable to both the light-markup adherents _and_ the wysiwyg folks, and i think i cracked that nut. i'd like your feedback on pre-release versions of some new stuff i'll have soon. e-mail me at bowerbird@aol.com if you'd like to play... and again, best of luck to the guardian people on this! -bowerbird

derefr 13y ago
That said, a plain contentEditable is just fine already if you can prevent the combinatoric explosion of browsers+OSes. Like, say, if you're shipping a node-webkit application.

snowwrestler 13y ago

I don't understand why companies and CMS projects think that everything needs to happen in the browser. Especially in situations like publishing, when the content creation is being done 100% by people under employment or contract. Give them a native app or browser plugin for authoring, and you can solve all these problems with much greater sophistication. In the distant past I used to use Microsoft Content Management Server to power websites. It lacked most of the modern features of a web CMS, but it provided a native app and IE plugin for authoring. In terms of code control and consistency it kicked the ass of even the best JS libraries available today. A native authoring app, side loaded onto employee machines, would be a much more powerful authoring solution. It would produce clean HTML code and push it into the CMS via an API call.