[whatwg] Styling <details>
Brett Zamir
brettz9 at yahoo.com
Wed Jan 2 18:54:25 PST 2013
On 1/3/2013 4:35 AM, Anne van Kesteren wrote:
> On Wed, Jan 2, 2013 at 8:53 PM, Ian Hickson <ian at 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
More information about the whatwg
mailing list