Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example request: DIY WYSIWYG #104

Open
grepsedawk opened this issue Jul 10, 2017 · 17 comments
Open

Example request: DIY WYSIWYG #104

grepsedawk opened this issue Jul 10, 2017 · 17 comments

Comments

@grepsedawk
Copy link
Collaborator

No description provided.

@brandondees
Copy link
Collaborator

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

@snuggs
Copy link
Member

snuggs commented Jul 10, 2017

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.
capture d ecran 2017-07-10 a 18 46 55

@snuggs
Copy link
Member

snuggs commented Jul 10, 2017

@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

@snuggs
Copy link
Member

snuggs commented Jul 10, 2017

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

@grepsedawk
Copy link
Collaborator Author

@snuggs why does it break specs? Where does it say that?

@snuggs
Copy link
Member

snuggs commented Jul 11, 2017

@pachonk must go through #86 thoroughly. Fully documented in description.

capture d ecran 2017-07-10 a 20 03 00

@grepsedawk
Copy link
Collaborator Author

How about <wysiwyg-editor>?

@snuggs
Copy link
Member

snuggs commented Jul 11, 2017

How about <text-editor> @pachonk

@snuggs
Copy link
Member

snuggs commented Jul 11, 2017

#CATAT /cc @tmornini

@grepsedawk
Copy link
Collaborator Author

CATAT?

@grepsedawk
Copy link
Collaborator Author

I'm fine with <text-editor> as long as the main example page mentions the term wysiwyg at least once.

@brandondees
Copy link
Collaborator

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.

@snuggs
Copy link
Member

snuggs commented Jul 11, 2017

@pachonk can even wrap the acronym in a <abbr title='What You See Is What You Get'>WYSIWYG</abbr> if ya like ;-)

@snuggs
Copy link
Member

snuggs commented Jul 16, 2017

@pachonk found this as a great benchmark.#salue @brandondees

https://jaredreich.com/pell

@grepsedawk
Copy link
Collaborator Author

@snuggs
Copy link
Member

snuggs commented Aug 24, 2017

yeah was checking this out @pachonk interesting.

@grepsedawk
Copy link
Collaborator Author

It looks more snuggsi style already, might be easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants