Post AOruYuNcCI8VTJzk3c by alcinnz@floss.social
 (DIR) More posts by alcinnz@floss.social
 (DIR) Post #AOruYrwFH53RtrAr7Q by alcinnz@floss.social
       2022-10-23T18:51:48Z
       
       0 likes, 0 repeats
       
       Yesterday I discussed my ambition for a CSS WYSIWYG, so it should come as no surprise I also want a HTML WYSIWYG! These editors would be entirely seperated within the same browser.The HTML WYSIWYG would need to be more deeply integrated into the browserengine to be called a WYSIWYG. Especially the inline-text layout engine.I would have a bottombar for inserting/replacing HTML tags around the selected text & a sidebar for editting HTML attributes when present.1/3?
       
 (DIR) Post #AOruYsQjRjRPQPRCdc by alilly@solarpunk.moe
       2022-10-23T19:01:18Z
       
       1 likes, 0 repeats
       
       @alcinnz One of my issues with WYSIWYG is that it encourages visual thinking. "How do I make it look like I want" rather than "how do I communicate what I'm trying to." HTML is supposed to be a semantic language, and thinking visually can lead authors in the wrong directions.That said I think WYSIWYG is a step in the right direction compared to using a text editor. Web user-agents should be able to author as well as browse, and an HTML editor should be able to show you what you've written.
       
 (DIR) Post #AOruYt0tHIMfEYM4zw by alcinnz@floss.social
       2022-10-23T19:04:35Z
       
       0 likes, 0 repeats
       
       @alilly Yes, this is a concern of mine & very much guides my design. Its why I seperate the CSS & HTML WYSIWYG editors into their own modes!Also why I'm displaying element outlines & labels on the page. Make the tree visual within the WYSIWYG pane! (Oooo, forgot to mention: hover would trigger these outlines too...)
       
 (DIR) Post #AOruYtNZuwVqMuyCMS by alilly@solarpunk.moe
       2022-10-23T19:05:55Z
       
       0 likes, 0 repeats
       
       @alcinnz I might mark the elements with semantic names rather than their literal tagnames; e.g. "attention" rather than <b>
       
 (DIR) Post #AOruYtYDHP1GttwgwC by alcinnz@floss.social
       2022-10-23T19:01:17Z
       
       0 likes, 0 repeats
       
       I'd handle keypresses like you're used to (again, if I don't write that event handling I'm not adding WYSIWYG to my browser engine), and for both internationalization & accessibility I'd need to be able to temporarily splice styled text into my style-tree.Double-clicking would broaden your highlight to the containing or parent element. The elements containing your selected text will be given outlines & labels.In sidebars elements & attributes would link to MDN documentation.2/3!
       
 (DIR) Post #AOruYti8gUxXOgacPQ by alilly@solarpunk.moe
       2022-10-23T19:02:54Z
       
       0 likes, 0 repeats
       
       @alcinnz My first instinct is a document tree left and a preview pane right but that feels disjointed. How does one encourage semantic rather than visual authoring in the design of the editing tool? I don't know.
       
 (DIR) Post #AOruYtlgTJnLZgFRw0 by alilly@solarpunk.moe
       2022-10-23T19:07:33Z
       
       0 likes, 0 repeats
       
       @alcinnz My biggest concerns are with getting elements of the same visual effects but different semantics mixed up; the best example is <em> vs. <i> vs. <span style="font-style: italic">.
       
 (DIR) Post #AOruYuNcCI8VTJzk3c by alcinnz@floss.social
       2022-10-23T19:17:06Z
       
       1 likes, 0 repeats
       
       @alilly Yeah, the <em> vs <i> issue is tricky, even working in code webdevs don't get this right. Giving them good localized labels & slightly burying <i> comes to mind...As for <span style="font-style: italic">, I'd bury <span> deepest & require users to know how to use the style attribute. Make this attribute purposefully unfriendly. You can use it, but I won't help you do so.
       
 (DIR) Post #AOruYul0nIqqdswQWe by alilly@solarpunk.moe
       2022-10-23T19:18:51Z
       
       1 likes, 0 repeats
       
       @alcinnz Except that, knowing the semantics of the two well, I actually find myself using <i> more than <em>. It turns out a lot of uses for italics are "idiomatic" rather than "emphatic."
       
 (DIR) Post #AOruYvIgm5n2KKhK1A by alcinnz@floss.social
       2022-10-23T19:11:32Z
       
       0 likes, 0 repeats
       
       Context menus or drag&drop would allow embedding media in the page. Which I'd run compression commands over to encourage good webdev habits.Then there's the question of table editting, haven't figured that out...In the elements menu I'd have links to open the attributes editor or <head> editor. And I'm being reminded that I neglected to say I'd localize tag & element names.2.5/2.5 Fin!
       
 (DIR) Post #AOrugYGaIY9fCmLouG by lanodan@queer.hacktivis.me
       2022-10-23T19:27:00.897169Z
       
       0 likes, 0 repeats
       
       @alilly @alcinnz Well, maybe the preview part could still be editable? This way you can see the mess that the WYSIWYG editor does but still have one.It's a bit how I wish to edit SVGs.
       
 (DIR) Post #AOrxWXKlD7cXHNDik4 by tusooa@kazv.moe
       2022-10-23T19:59:51.272264Z
       
       0 likes, 0 repeats
       
       @alcinnz @alilly https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i<i>: The Idiomatic Text elementThe <i> HTML element represents a range of text that is set off from the normal text for some reason, such as idiomatic text, technical terms, taxonomical designations, among others. Historically, these have been presented using italicized type, which is the original source of the <i> naming of this element.
       
 (DIR) Post #AOsdFT82UvCr2b5pKq by jollyrogue@social.tulsa.ok.us
       2022-10-24T03:22:49Z
       
       1 likes, 0 repeats
       
       @alilly This is why I say we should give up on HTML as a GUI formatting language and switch to a true typesetting language, like everyone really wants.Make HTML the input language, and PS, LaTeX, or something else for output.@alcinnz @Seirdy