Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WYSIHTML5: A better approach to rich text editing

xing.github.com

Post reply on HN
Print view View original

41–50 of 82 posts

Re: WYSIHTML5: A better approach to rich text editing

#41

Post by sundeep_b »

junto wrote: post #21

I'm using the Twitter Bootstrap styled version of this in a current project. It looks stunning: http://jhollingworth.github.com/bootstrap-wysihtml5/

Cool! That's the first thing that hit my mind - how would this look in bootstrap? Thanks for doing and sharing this!

Re: WYSIHTML5: A better approach to rich text editing

#42

Post by zalew »

legutierr wrote: post #16
laktek wrote: post #6

Earlier quoted context omitted.

Depends on the use case. If you are using it in as a website authoring tool, it makes sense to store the rich-edit user input as HTML itself. However, in a scenario like commenting or composing a message (where only limited editing options are available), storing in a format such as Markdown make sense.

Are you aware of any such editor that does store the data in Markdown or something similar?

http://markitup.jaysalvat.com/home/

Re: WYSIHTML5: A better approach to rich text editing

#43

Post by Akram »

laktek wrote: post #6
lunaru wrote: post #4

Wouldn't it be more desirable to have these WYSIWYG editors serialize to a non-HTML markup (like textile or markdown) to reduce the hassle of user-input sanitization on the back-end? (e.g. stripping script and iframe tags). What's best-practice these days for storing and displaying rich-edit user input?

Depends on the use case. If you are using it in as a website authoring tool, it makes sense to store the rich-edit user input as HTML itself. However, in a scenario like commenting or composing a message (where only limited editing options are available), storing in a format such as Markdown make sense.

even in comments a whitlist of markup would save a lot of code on both the ends.

Re: WYSIHTML5: A better approach to rich text editing

#44

Post by junto »

sundeep_b wrote: post #41
junto wrote: post #21

I'm using the Twitter Bootstrap styled version of this in a current project. It looks stunning: http://jhollingworth.github.com/bootstrap-wysihtml5/

Cool! That's the first thing that hit my mind - how would this look in bootstrap? Thanks for doing and sharing this!

Just to be clear. I didn't write this! I just used it.

The credit for writing this goes to James Hollingworth: https://github.com/jhollingworth

Re: WYSIHTML5: A better approach to rich text editing

#45

Post by nosierbatiste »

eliben wrote: post #18

IE in browser support: IE8+ yay ;-)

We officially support IE7 and IE8 in Aloha. I say officially, because, although it does seem to work, it doesn't work very well (at all). IE does some weird stuff with the DOM, especially inside a contenteditable (certain combinations of DOM elements completely mess up the structure if it's inside a contenteditable, but not if it's outside).

Re: WYSIHTML5: A better approach to rich text editing

#48

Post by emp_ »

lunarscape wrote: post #40
eliben wrote: post #18

IE in browser support: IE8+ yay ;-)

Out of curiosity is it working in IE8 for you? Doesn't appear to fully work for me using IE8 on XP. The editor buttons and most of the page don't appear.

The editing does work for me, no buttons show but I am not sure if the demo is tailored to show that off.

On IE7 nothing really happens.

Re: WYSIHTML5: A better approach to rich text editing

#49

Post by robin_reala »

laktek wrote: post #27
robin_reala wrote: post #17

Earlier quoted context omitted.

Aloha is more than a meg of JS as it stands and the documentation is pitiful.

I'm a contributor to Aloha and recently project underwent a huge re-write to cut down the cruft. Next release, will use a light weight UI based on jQuery and also switching to a newer command API based on W3C's editing API will also make things more faster (and easier). Main issue with the documentation was the rapid changes to the API in the past. Since the API is getting stable there will be more concern on improvi…

Sorry, just re-read my comment and realised I came across as yet another of those entitled and grumpy anonymous commenters you find online. For what it’s worth, I like Aloha as integrated into the Aloha site, I just failed miserably despite much effort to integrate seamlessly into a recent project. I was aware of the jQuery UI rewrite but the branch didn’t seem to have had any commits in the previous two weeks when I looked so I assumed progress was slow. Glad to hear there’s more definitive plans.

I stand by my comment about the lack of documentation though. I appreciate that it’s often difficult to get people to contribute to docs over code, but it’s pretty imperative for a project like this that there’s at least an easy integration walkthrough and a handful of examples showing common customisations.

Re: WYSIHTML5: A better approach to rich text editing

#50

Post by sandfox »

decklin wrote: post #47
TazeTSchnitzel wrote: post #46

Valid HTML5 markup? It's certainly not semantic. should be , should be

You might want to take a look at this: http://www.whatwg.org/specs/web-apps/current-work/multipage/...

You might want to read this bit from that section: "The b element should be used as a last resort when no other element is more appropriate. In particular, headings should use the h1 to h6 elements, stress emphasis should use the em element, importance should be denoted with the strong element, and text marked or highlighted should use the mark element."

From the looks of it - while just about legal, it's the worst option going. etc are far more preferable and 'right'

Post reply on HN