Re: [whatwg] Styling <details>

On 1/3/2013 4:35 AM, Anne van Kesteren wrote:
> On Wed, Jan 2, 2013 at 8:53 PM, Ian Hickson <ian@hixie.ch> wrote:
>> Like most widgets, I think the answer is Web Components.
> As far as I can tell styling form controls is an unsolved problem and
> Components does not seem to be tackling it. We always play the
> Components card (and before that the XBL card), but the work thus far
> does not allow for altering how <input> is displayed, or subclassing
> <textarea> somehow.
>
> After a decade of waiting for this, I think it might be time to start
> calling this vaporware.

In my ideal world, with HTML deprived of XML or XML-like extensibility 
(no entities or namespaces), and even with what Web Components or the 
like could do, and with JavaScript already being able to encompass this 
functionality, there appears to me to be a far greater need for making a 
standard and familiar/friendly JSON/JavaScript way to represent HTML 
than an HTML way to represent JavaScript. Such a format would also seem 
a whole lot easier to implement than Web Components.

I'd go so far as to hope for a special content-type which could avoid 
the need for HTML and even CSS syntax altogether.

I have been working on a syntax which I call JML (for JSON/JavaScript 
Markup Language, but pronounced as Jamilih, meaning Beauty in Arabic, 
and also my daughter's name--also perhaps a nice counterpart to the 
masculinish "JSON"), requiring, relative to JsonML, an additional array 
around all children for the sake of easier modularity (e.g., so that 
inline functions could be called to return fragments of text and/or 
children and drop in as an element's children), and also allowing an 
easy-to-learn HTML/XML-leveraging means of extensibility shown through 
examples below.


exports.main = // Use of this line would allow the template below to be 
preceded (above) by function definitions, but could perhaps also be 
dropped to allow a simpler JSON or JSON-like content-type to similarly 
be renderable as HTML without it

[ // Optional document meta-attributes could come here
['html', [
     ['head', [
         ['script', [
             // A JSON format sans functions could be possible, but 
allowable for convenience in templating
             {$script: function (onReady) {
                 require(['depend1'], function (depend1) {
                     onReady(function () {
                         document.body.appendChild(['p', ['World']]);
                         depend1('no additional script tags needed for 
modularity');

                         // Ready and easy conversion
                         var jml = ['b', ['Hello']], html = 
'<b>Hello</b>', dom = document.createElement(jml);
                         jml === html.toJML() &&
                             jml === dom.toJML() &&
                                 html === jml.toHTML() &&
                                     html === dom.toHTML() &&
                                         dom === html.toDOM() &&
                                             dom === jml.toDOM(); // true
                     });
                 });
             }}
         ]],
         ['style', [
             // Non-array objects would normally represent attributes, 
but when prefixed with the
             //   reserved '$', other features become possible for HTML 
(or XML)
             {$css: [
                 ['p[greeting]', ['color', 'blue']]
             ]
         ]]
     ]],
     ['body', [
         'text',
         ['p', {'class':'greeting'}, ['Hello!']],
         {'$#x': '263A'},
         {$comment: 'Finished file!'}
     ]]
]]
]

I think the above would be very easy for existing developers and 
designers to learn.

While a "declarative" syntax is indeed helpful, developers often seem to 
believe that a declarative syntax is only possible through HTML or CSS. 
Declarative syntax is known primarily for being about avoiding 
unnecessary reference to control flow, but with the likes of XSL being 
able to say prove loop counts, and with JavaScript array extras now 
allowing function-based iteration without loop counts, it seems 
meaningless to make distinctions at a language level between declarative 
and imperative paradigms. Developers also seem to use "declarative" to 
refer to a syntax that is not only more human-readable (unlike 
non-transparent DOM objects), but also easily parsable--unlike raw 
JavaScript (or HTML), but possible with a subset of JavaScript as JML 
above. It could be optionally extended (by 3rd parties if nothing else) 
to support DOM methods, XPath/CSS Selectors, XSL, etc. Developers could 
effortlessly move between static or dynamic representations of HTML 
(without having to say first convert static HTML into 
line-break-cumbersome, syntax-highlighter-unfriendly JavaScript strings).

I would think something like the above could be fleshed out to fill this 
need and could foster code reuse with "HTML" and "CSS" and in the 
process get designers better familiar with JavaScript (perhaps creating 
document with, if the proposed content-type is not eventually replaced 
by or complemented with a CoffeeScript equivalent).

Although I know it can be done as a code library, it would be nice to be 
able to replace the need for <script> tag cruft at all (and also for 
leveraging native performance).

Thank you for the consideration!
Brett

Received on Thursday, 3 January 2013 02:55:04 UTC