devpunks
Example request: DIY WYSIWYG
heavyweight WYSIWYG html editor solutions like TinyMCE still dominate the market even though lighter weight alternatives have sprung up here and there... I think snuggsi is a perfect way to approach creating a light and fast and more importantly, easily customizable, WYSIWYG text / markup / markdown editor
This is amazing as need to come up with a document editor on a project with @robcole. Timing is perfect actually so i get to really knock this out of the park.
@brandondees @pachonk will need your guidance on them as i've avoided them like the plague.
Will start as soon as #85 is merged.
Can we agree that at minimum a WYSYWIG is nothing more than a glorified <textarea> with a <menu>?
Can we PLEASE put the <menu> at the footer a-la gmail? Maybe because i'm left handed. Just up top seems pointless as when you are typing text goes to bottom of page. As it does with this very message.
@pachonk assigning this one to you to quarterback. I'll run touchdowns if you toss me the ball. Quarterback keeps the cadence. ;-) #FreeJewelry 💍 💎
/cc @albertoponti @cristhiandick
Let's first start with a name.
<wysywig> is not available as it breaks custom element specs.
<wysywig-> CAN BE a component name (We are discussing element namespacing etc. here #86 )
That said i think needs to be some re-invention. MUST be something friendlier than an acronym.
<text-box contenteditable=true> perhaps?
First thing we should do is go over this documentation. Then can understand the 140LOC of a stick figure implementation they have. I bet i can trim that down by about 40% @pachonk @brandondees.
@halorium may want to keep an eye out on ☝️ this issue/PR.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
I'm fine with <text-editor> as long as the main example page mentions the term wysiwyg at least once.
I agree, menu should be bottom-anchored by default, preferably, and IMHO should assume a preference for minimalism rather than including everything by default. formatting buttons should probably be designated in some kind of groupings which could be added / omitted easily together, without removing the ability to add / skip individual buttons.
I believe the button features themselves probably can / should be nested custom element components of their own, making this a modular and extensible system by default (:unicorn: inside of 🦄 ). the architecture for how a button and text / code editing behavior should be structured to integrate with a parent editor container and menu bar, I don't have much idea about yet but I'll leave that to you who are actively working on it. I believe it should hypothetically be feasible to make this very versatile and flexible.
<wysiwyg-editor> works for me as a default tag choice but i'd also consider that folks might want to make a lot of their own custom variations so maybe things like <code-editor> <rich-text-editor> <html-editor> <github-markdown-editor> etc. may be worth considering, or perhaps coming up with a naming convention that allows these kinds of things to live comfortably together. for alphabetic sorting purposes i sometimes consider appending the modifier bit of a name, so that'd mean <editor-html> <editor-markdown> <editor-markdown-wysiwyg> etc.
i don't think it's what we're trying to build here but i can foresee a wysiwyg and text-only variant of any given variation of this concept, so maybe wysiwyg is an actual boolean attribute and not part of the tag name.
@pachonk can even wrap the acronym in a <abbr title='What You See Is What You Get'>WYSIWYG</abbr> if ya like ;-)
@pachonk found this as a great benchmark.#salue @brandondees
https://jaredreich.com/pell