- From: Brett Zamir <brettz9@yahoo.com>
- Date: Thu, 03 Jan 2013 10:54:25 +0800
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Cameron McCormack <cam@mcc.id.au>, whatwg <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
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