I have actually spent a lot of time looking for a solution for this. Stackoverflow is my last resort. Before I dive in I would like to describe my requirements.
My requirements,
I need an editor like slack that automatically converts markdown to relevant TextStyle or html. For example if I type, ## Hello and press enter. it is styled as H2 styled text.
Moreover, I also need to show a dropdown whenever I press # or # to select from a list of options.
In short, I need something like quip, slite or medium.
I was hoping that this will be easy in flutter, given half of these features are already there in Google's Gmail and other apps by google by havent yet found a single library that meets these requirements.
What I have already tried?
Quil: I found out by flutter_quill but for that I have to stick to a toolbar on the top. And no mentions support.
Zefyr and html_editor: I have tried these, but they are very buggy and slow. Moreover, they have very limited documentations.
Custom Flutter: Medium-like Text Editor. This is the most promising solution but it is lacking one essential feature of text editor. The article proposes that I divide the entire input field into multiple text fields which I can control using state. But this has one big problem that is, what if I want to select the entire body of text. Any hacks on this will be well appreciated.
If you have any questions and if the question isn't clear enough, please free to comment down below.
category links for which i haven't created custom pages are displaying as red links. i was under the impression that actually creating a page is optional for category pages.
a typical situation can be :
an article is called up.
one of the category links at the bottom of the page will be red.
clicking on the link will take me to a valid category summary.
clicking on another category link at the bottom of the article (a white one) will
also take me to a valid category summary.
returning to the article, the second category link is now also red.
is there a way to tweak the wiki so category pages are displayed in white, regardless of whether they have a custom page created for them ?
the wiki is running MediaWiki 1.29.1.
as it turns out, the problem was that the styling for a.new and a.new:visited appeared with a higher precedence than that for catlinks. unless the desire is to require every single wiki to have every single category be fully defined [i.e., providing a landing page for each category], this isn't a good approach.
one of the great powerful features of mediawiki is its capability that allows admins and maintainers to categorise articles as they wish without requiring them to create a landing page for every single category. however, if this is your goal, the styling won't support it as-is, due to this precedence problem. you can insist on precedence for catlinks however, by appending !important. although many people detract from the use of !important, this use case is pretty much textbook for the reason it was designed in the first place.
if your need is more in line w/that envisioned by the maintainers of the current mediawiki release [i.e., you want to have a hand-designed landing page for every single category and have no need for truly automatically-generated categories], this is a non-issue.
The colors are set using CSS, you should create new CSS and add it to MediaWiki:Common.css to apply it to ask skins. If this page does not yet exist just create it.
The ‘.catlinks’ class controls the formatting of links to categories, and the colors for wanted pages are defined by the ‘.new’ class, eg a.new, a:new:visited.
The original code can be found in the mediawiki/resources/src/mediawiki.skinning/interface.css file.
Just add CSS to fix the font colors to those you choose to Common.css, eg
.catlinks,
.catlinks a.new,
.catlinks a.new:visited {
color: #0645ad;
}
I am just wondering is there any plugin to create dynamic content for a page i.e something similar to a data repeaters in .net. To make it simple it should be a section that should contains 5 to 6 fields/property like
heading
heading 2
image
content - rich text editor
info
This must be in repeatable control so that the editor can add any number of these section a page and all these should be displayed in a single page.
Is there a plugin for the above functionality or what is the best way to achieve this.Any help would be greatly appreciated.
Thanks
Aneesh
You can achieve this without any plugins.
Create your repeatable section (containing the relevant fields) as a document type, and then use the multi-node picker in another document type to select one or many of the sections.
So for example, I could have a FAQs page (which uses a document type called "FAQs Page"), and I want to be able to add multiple question and answers to this page. I could set up a document type called "Question". This will contain two fields: Question and Answer.
On the "FAQs Page" document type, I would add a multi-node picker field called "Questions". This way, an author could select multiple "Question" nodes to appear on the FAQs page.
You would obviously need the code to output this, and also you would create a data type that inherited from multi-node picker, so that you could limit the selection to only Question nodes.
There is also the Repeatable Custom Content datatype which works well but does not support all data types. But it does support all the ones you need for your stated purpose (textstring, media picker, richtext area, etc).
You can find it here: http://our.umbraco.org/projects/backoffice-extensions/repeatable-custom-content I've used it a few times and it works really well in certain situations (e.g. where the items will not be shared across different pages of your site).
If you are sharing content components across multiple pages then #Digbyswift's solution is perfect.
I've always Digbyswifts method, but whilst looking for an alternate solution tonight I found this plugin, which is excellent for those situations where creating lots of widget nodes feels like overkill. It's licensed but the free older version is also available.
http://inaboxdesign.dk/blog/widget-builder-for-umbraco/
How does the Reader function of Mobile Safari in iOS 5 work? How do I enable it on my site. How do I tell it what content on my page is an article to trigger this function?
A lot of the answers posted here contain false information. Here are some corrections/clarifications:
The <article> element works fine as a wrapper; Safari Reader recognizes it. My site is an example. It doesn’t matter which wrapper element you choose, as long as there is one, other than <body> or <p>. You can use <article>, <div>, <section>; or elements that are semantically incorrect for this purpose, like <nav>, <aside>, <footer>, <header>; or even inline elements like <span> (!).
No headings are required for Reader to work. Here’s an example of a document without any <h*> elements on which Reader works fine: http://mathiasbynens.be/demo/safari-reader-test-3
I posted some more details regarding my findings here: http://mathiasbynens.be/notes/safari-reader
I've tested 100 or so variations of this on my iPhone in order to figure out what triggers this elusive Reader state. My conclusions are as follows:
Here is what I found had an impact:
Having around 200 or more words (or 1000 characters including whitespace) in the article you want to trigger the "Reader" seems necessary
The reader was NEVER triggered when I had less than 170 words; although it was sometimes triggered when I had 180 or 190 words.
Text inside certain elements such as <ol> or <ul> (that are not typically used to contain a story) will not count towards the 200 words (they will however be displayed in the reader if the reader is triggered for other reasons)
Wrapping the 200 words in a block element such as a <div> or <article> seems necessary (that said, I'd be surprised if there were any websites where that was not already the case)
For full disclosure, here is what I found did NOT have an impact:
Whether using a header or not
Whether wrapping the text in a <p> or letting it flow freely
Punctuations (ie removing all periods, commas, etc, did not have an impact)
It seems the algorithm it is based on is looking for p-Tags and it counts delimiters like "." in the innerText. The section (div) with the most points gets the focus.
see:
http://lab.arc90.com/experiments/readability/
Seems to be the base for the Reader-mode, at least Safari attributes it in the Acknowledgements, see:
file:///C:/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90 ( Readability )
Copyright © Arc90 Inc.
Readability is licensed under the Apache License, Version 2.0.
This question (How to disable Safari Reader in a web page) has more details. Copied here:
I'm curious to know more about what triggers the Reader option in Safari and what does not. I wouldn't plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I've learned so far with some basic playing around:
You need at least one H tag
It does not go by character count alone but by the number of P tags and length
Probably looks for sentence breaks '.' and other criteria
Safari will provide the 'Reader' if, with a H tag, and the following:
1 P tag, 2417 chars
4 P tags, 1527 chars
5 P tags, 1150 chars
6 P tags, 862 chars
If you subtract 1 character from any of the above, the 'Reader' option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
Setting for P tags removes them from the count
Setting display to none, and then showing them 230ms later with Javascript avoided the Reader option too
I'd be interested if anyone can determine this in full.
Both Firefox and Chrome have the similar plugin named iReader. Here is its project with source code.
http://code.google.com/p/ireader-extension/
Read the code to get more.
I was struggling with this. I finally took out the <ul> markings in my story, and viola! it started working.
I didn't put any wrapper around the body, but may have done it by accident.
HTML5 article tag doesn't trigger it on my tests. It also doesn't seem to work on offline content (i.e. pages saved on your local machine).
What does seem to trigger it is a div block with a lot of p's with a lot of text.
The p tag theory sounds good. I think it also detects other elements as well. One of our pages with 6 paragraphs didn't trigger the Reader, but one with 4 paragraphs and an img tag did.
It's also smart enough to detect multi-page articles. Try it out on a multi-page article on nytimes.com or nymag.com. Would be interested to know how it detects that as well.
Surprising though it may be, it indeed does not pay any attention to the HTML5 article tag, particularly disappointing given that Safari 5 has complete support for article, section, nav, etc in CSS--they can be styled just like a div now, and behave the same as any block level element.
I had specifically set up a site with an article tag and several inner section tags, in prep for semantic HTML5 labeling for exactly such a purpose, so I was really hoping that Safari 5 would use that for Reader. No such luck--probably should file a bug on this, as it would make a great deal of sense. It in fact completely ignores most of the h2 level subheads on the page, each marked as a section, only displaying the single div that adheres to the criteria mentioned previously.
Ironically, the old version of the same site, which has neither article, section, nor separating div tags, recognizes the whole body for display in Reader.
See Article Publishing Guidelines.
Here are APIs about how to read and parse: Readability Developer APIs. There's already a project you can refer: ruby-readability.
A brief history:
The Safari Reader feature since Apple's Safari 5 browser embeded a codebase named Readability, and Readability started off as a simple, Javascript-based reading tool that turned any web page into a customizable reading view. It was released by Arc90 (as an Arc90 Lab experiment), a New York City-based design and technology shop, back in early 2009. It's also embeded in Amazon Kindle and popular iPad applications like Flipboard and Reeder.
I am working on algorithms for cleaning web-sites from information "waste" similar to Safari Reader feature. It's not so good as readability but has some cool stuff.
You can learn more at smartbrowser.codeplex.com project page.
I have four textareas in my form. TinyMce editor applies to only first row of the textarea, remaining rows for textareas dont get editor in google chrome. It works fine in firefox instead.
It's hard to know without seeing the code, but I'm going to go ahead guess that you are referencing your multiple textareas using the same ID. IDs must be unique - so give them each their own individual ID and then attach the editor with four separate calls, or reference them by class instead.
Or attach some code for us to take a look at.