Make HTML Component set a true representation of HTML elements

Harbs commented 6 years ago

The HTML component set is a bit sloppy. It's incomplete and it's not possible to use it in all cases as pseudo-HTML markup. Ideally, it could be used in the same structure and using the same attributes and properties that you'd use in HTML.

Below is a short-list of the HTML components and whether they are completed.

[x] A
[x] Code
[x] Div
[x] H1
[x] H2
[x] H3
[x] H4
[x] H5
[x] H6
[x] I
[x] Input
[x] Li
[x] Ol
[x] Option
[x] P
[x] Pre
[x] Select
[x] Span
[x] Td
[x] TextNode
[x] Th
[x] Ul
[x] Hr
[x] Em
[x] Strong
[x] Small
[x] S
[x] Img
[x] Table
[x] Tbody
[x] Thead
[x] Tfoot
[x] Tr
[x] Col
[x] Colgroup
[x] Button
[x] Form
[x] Label
[x] Textarea
[x] B
[x] U
[x] Caption

Harbs commented 6 years ago

For reference, here's a full list of HTML elements. I'm not sure which ones make sense to have components for and which ones don't.

<html> <head> <title> <base> <link> <meta> <style> <body>
<article> <section> <nav> <aside> <h1> <h2> <h3> <h4> <h5>
<h6> <hgroup> <header> <footer> <address> <p> <hr> <pre>
<blockquote> <ol> <ul> <menu> <li> <dl> <dt> <dd> <figure>
<figcaption> <main> <div> <a> <em> <strong> <small> <s>
<cite> <q> <dfn> <abbr> <ruby> <rt> <rp> <data> <time>
<code> <var> <samp> <kbd> <sub> <sup> <i> <b> <u> <mark>
<bdi> <bdo> <span> <br> <wbr> <ins> <del> <picture> <source>
<img> <iframe> <embed> <object> <param> <video> <audio>
<track> <map> <area> <table> <caption> <colgroup> <col>
<tbody> <thead> <tfoot> <tr> <td> <th> <form> <label> <input>
<button> <select> <datalist> <optgroup> <option> <textarea>
<output> <progress> <meter> <fieldset> <legend> <details>
<summary> <dialog> <script> <noscript> <template> <slot> <canvas>

Harbs commented 6 years ago

And these are the ones which have no components at all yet:

<html> <head> <title> <base> <link> <meta> <style> <body>
<article> <section> <nav> <aside>
<hgroup> <header> <footer> <address> <hr>
<blockquote> <menu> <dl> <dt> <dd> <figure>
<figcaption> <main> <em> <strong> <small> <s>
<cite> <q> <dfn> <abbr> <ruby> <rt> <rp> <data> <time>
<var> <samp> <kbd> <sub> <sup> <b> <u> <mark>
<bdi> <bdo> <br> <wbr> <ins> <del> <picture> <source>
<img> <iframe> <embed> <object> <param> <video> <audio>
<track> <map> <area> <table> <caption> <colgroup> <col>
<tbody> <thead> <tfoot> <tr> <th> <form> <label>
<button> <datalist> <optgroup> <textarea>
<output> <progress> <meter> <fieldset> <legend> <details>
<summary> <dialog> <script> <noscript> <template> <slot> <canvas>

piotrzarzycki21 commented 6 years ago

I think adding missing components may gets some attraction, but not sure either if it should be all of them. I don't even know some of them. :)

Maybe make some list which you think are important. For example does that make sense add "table", we have it in Basic.

Harbs commented 6 years ago

Here's a nice reference which explains what they all are: http://www.htmlquick.com/reference/tags.html

I'll try to make a list of ones I think are necessary.

Harbs commented 6 years ago

Here's structure-related elements. These are probably less important than the functional ones:

<article> <section> <nav> <aside>
<hgroup> <header> <footer> <address>
<blockquote> <menu> <dl> <dt> <dd> <figure>
<figcaption> <main>

And functional ones:

<hr> <em> <strong> <small> <s> <img> <iframe> <embed> <video> <audio> <track>
<map> <area> <table> <caption> <colgroup> <col>
<tbody> <thead> <tfoot> <tr> <th>
<button> <datalist> <fieldset> <form> <input> <label> <legend> <meter> <optgroup> <option> <output> <progress> <select> <textarea> 
<details> <dialog> <menu> <menuitem> <summary>

Harbs commented 6 years ago

I included all form related elements even though some might be rarely used.

aharui commented 6 years ago

I'm more interested in a division between which HTML tags are "inefficient" or "unnecessary" to be replicated and wrapped into a royale component. For example p, i, b, br, and some others are effectively text formatting tags and are rarely programmatically accessed if at all. They should be able to be used in the innerHTML or htmlText String properties, but not have actual components.

IMO, if we prove that Table can work (maybe we should just move the one from Basic to HTML) and maybe also Form, we can feel pretty good that the HTML file format is compatible with the MXML file format and other tags can be added later as folks need them.

Still, I don't think that HTML snippet-pasting is an important thing for us to support. It would be great if it "just works", but I still think we want folks to use the MXML workflow and our APIs as they should be more efficient/productive than using bare HTML.

Harbs commented 6 years ago

My vision is that the HTML package should be a separate namespace and should have a one-to-one matchup with HTML tags.

I agree that the preferred method would be to use "real" Royale components which would encourage efficient markup and the right mix of functionality, but if my experience with my app is indicative, there will be edge cases where components don't exist and being able to easily incorporate HTML snippets is a valuable feature to have.

I think a separate namespace is very important to make it clear that these are not "true" Royale components. I would give them a namespace of library://ns.apache.org/royale/html and a standard prefix of i.e. <html:Input/> That would make it very clear what are royale components and what are "just" html markup.

piotrzarzycki21 commented 6 years ago

I agree with @Harbs with that if I don't have an component in Royale - I'm not necessary trying to recreate some new one, but rather I'm switching myself on thinking in HTML way and use pure HTML markups. We can make here stop and wait for people who will miss some pure HTML components, but should we ?

Harbs commented 6 years ago

I think I'm done with this list. We could probably use an example project which makes use of these.

apache / royale-asjs

Make HTML Component set a true representation of HTML elements #91