Re: [whatwg] Styling details
On Thu, 3 Jan 2013, Brett Zamir wrote:
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.
There've been proposals to do this at the language level, e.g.:
http://www.hixie.ch/specs/e4h/strawman
However, in practice I've found that you can pretty easily define two
functions in JS that make this work more or less sufficiently well.
The first function is E(), which returns an element. It's signature:
E(name, [attrs,] [children...])
...where attrs is an optional dictionary where:
- entries whose value is a string are added as content attributes with
the given value
- entries whose value is a number are added as content attributes with
the given value as a string
- entries whose value is true are added as content attributes with
the empty vlaue
- entries whose value is false are ignored
- entries whose value is a function are assumed to be IDL attributes that
are to be set to that function
- other entries throw an exception
...and where children is zero or more arguments where:
- values that are Element, Comment, and Text nodes are appended to the
element as children
- values that are DocumentFragments have their children appended to the
element in the same way
- values that are strings are appended as text nodes with the given value
- values that are numbers are appended as text nodes with the given value
converted to a string
- values that are arrays are recursively processed in the same way
- other values throw an exception
The second function is F(children...) which takes just the varargs like
the previous function, but returns a DocumentFragment instead.
So e.g.:
document.body.appendChild(F(
E('p', E('input', { type: 'button',
value: 'Demo',
onclick: function (event) { alert('Hello!') },
}),
' Press the button, ', name, '! ', // name is a string var
E('em', { class: 'beg' }, 'Please!';
It's not as pretty as E4H, but it's functional and way better than
constructing it using raw DOM calls.
For the record, the E4H equivalent would be:
document.body.appendChild(pinput type=button
value=Demo
onclick=alert('Hello!')/\
Press the button, {name}!\
em class=begPlease!/em/p/);
(If we did go down the E4H route, we'd have to find a better solution for
event handlers, though.)
[ // 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 = 'bHello/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 don't really see the advantage of such a format. What problem are you
solving here?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov dglaz...@chromium.org wrote: So I wouldn't call this exactly vaporware :) I cannot get it to work for select. But this is certainly interesting. It would require details to be defined in terms of shadow trees, or not? As otherwise the triangle in Chrome's implementation would not disappear so easily... -- http://annevankesteren.nl/
Re: [whatwg] Styling details
On Mon, Jan 7, 2013 at 2:25 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Jan 6, 2013 at 8:36 PM, Dimitri Glazkov dglaz...@chromium.org wrote: So I wouldn't call this exactly vaporware :) I cannot get it to work for select. Right. Here is WebKit's burn down list for all remaining elements to convert to be shadow tree-aware: https://bugs.webkit.org/showdependencytree.cgi?id=82313hide_resolved=1 But this is certainly interesting. It would require details to be defined in terms of shadow trees, or not? As otherwise the triangle in Chrome's implementation would not disappear so easily... While details is indeed implemented as a shadow tree in WebKit, it does not have to be. It does, however, need to be know how to interact with shadow trees. Specifically, the element has to pretend that its composition is defined in terms of insertion points: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees :DG
Re: [whatwg] Styling details
On Wed, Jan 2, 2013 at 9:10 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Jan 2013, Boris Zbarsky wrote: On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. [...] and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. Why not? This seems like a pretty core feature. Without being able to do this, how can anyone reliably extend an existing widget, for example? That's a good question! I am certainly interested in--and have been working on--solving these use cases. In fact, if you point your Chrome Dev/Canary to http://jsfiddle.net/nL747/, you will see that you can indeed style an existing details/summary combo just fine, using Shadow DOM (please pardon the bugs in WebKit details implementation, we know they exist and are fixing them) This is possible because Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#html-elements-and-their-shadow-trees), which in turn allows the author-created shadow trees to properly override (and even include) those UA-provided shadow trees. You should be able to do the same exact thing with every other element (though there's a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of the insides of the actual replaced content that will need to be first resolved by CSS WG). So I wouldn't call this exactly vaporware :) The remaining interesting question is how these shadow trees are created? There are three ways: 1) Using shadow DOM API, in plain JS, as shown in the fiddle. 2) Using Custom Elements ( http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html), which enables authors to extend existing HTML elements to create new widgets. 3) Using Decorators ( http://www.w3.org/TR/components-intro/#decorator-section) to give new shadow trees to existing elements. Hope this helps. :DG
Re: [whatwg] Styling details
On Jan 2, 2013 8:25 AM, fantasai fantasai.li...@inkedblade.net wrote: On 04/08/2011 05:05 AM, Lachlan Hunt wrote: One option is to define that the list-style-type 'disclosure-*' as magic values that mean to render a UA specific/platform dependent widget. But that differs from all other list-style-type values and doesn't seem quite right. The CSSWG discussed and agreed to add these to the draft back in 2011. Tab still hasn't edited it in, apparently. *pokes Tab* http://lists.w3.org/Archives/Public/www-style/2011Apr/0646.html Durp, sorry. Will do. ~TJ
Re: [whatwg] Styling details
On 04/08/2011 05:05 AM, Lachlan Hunt wrote:
One option is to define that the list-style-type 'disclosure-*' as magic values
that mean to render a UA specific/platform
dependent widget. But that differs from all other list-style-type values and
doesn't seem quite right.
The CSSWG discussed and agreed to add these to the draft back in 2011.
Tab still hasn't edited it in, apparently. *pokes Tab*
http://lists.w3.org/Archives/Public/www-style/2011Apr/0646.html
CSS3-UI, however, uses the 'appearance' property to render native looking
controls.
In theory, native widgets could be achieved instead by using a new 'appearance'
value like:
summary::marker { appearance: -x-disclosure; }
(Assuming the 'appearance' value handles the open/close states automatically,
and any animations that would be expected of
native controls)
The only value of 'appearance' that actually works IIRC is 'none'.
I'm not sure I'd recommend it as a good way forward for anything
since it's not clear how other values are supposed to work.
~fantasai
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Cameron McCormack wrote: I'm wondering if anybody has had any further thoughts on how summary and details should be made stylable. Like most widgets, I think the answer is Web Components. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Wed, Jan 2, 2013 at 8:53 PM, Ian Hickson i...@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. -- http://annevankesteren.nl/
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Anne van Kesteren wrote: On Wed, Jan 2, 2013 at 8:53 PM, Ian Hickson i...@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. Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. As far as I can tell, Web Components is doing the following: 1) Defining a way for authors to implement custom widgets. 2) Defining a way to maybe describe built-in custom widgets using the same language. It is not yet, but maybe sometime (this is pretty vaporware-ish so far) doing: 3) Defining a way that author styles can be applied to browser-defined custom widgets. and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. -Boris
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 i...@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 =
'bHello/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
Re: [whatwg] Styling details
On Wed, 2 Jan 2013, Boris Zbarsky wrote: On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. [...] and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. Why not? This seems like a pretty core feature. Without being able to do this, how can anyone reliably extend an existing widget, for example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On 1/3/13 12:10 AM, Ian Hickson wrote: On Wed, 2 Jan 2013, Boris Zbarsky wrote: On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. [...] and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. Why not? This seems like a pretty core feature. Without being able to do this, how can anyone reliably extend an existing widget, for example? First of all, I'm not actively working on Web Components, so I can't tell you why it is or is not doing something. Second, I suspect that the browser-defined widgets can end up with somewhat different per-platform implementations. And different per-browser behavior and so forth. So speccing them might end up being pretty nontrivial, and right now Web Components have bigger fish to fry (like allowing authors to define widgets). Long-term this is probably in the goals, but we're talking years. -Boris
Re: [whatwg] Styling details
I'm wondering if anybody has had any further thoughts on how summary and details should be made stylable. My initial feelings were along the lines of Tab's -- the disclosure widget feels very much like something that is created like a list bullet and matched with ::marker. But reading Ian's reply I'm beginning to think that this is inadequate, as some platforms may not use a small separate widget for expanding/collapsing the details at all, and thus at some point in the future a binding should be used to define the element's native behaviour, and authors could switch that off with binding:none to get a stylable element. But I also feel that authors should be able to get a useful, stylable presentation of the element without having to construct it themselves, e.g. by using the UA styles that Lachy suggested. Would it be feasible to have a native presentation of the element, which you could opt out of with binding:none, and to have something like Lachy's styles apply when the native binding isn't being used? When the native appearance is being used, should it be possible to target the disclosure widget with ::marker, or to be able to use list-style-type to change from the default disclosure widget, if the natural presentation of a details/summary for the platform is like a list bullet? If that is not the way the platform would present a details/summary, should attempting to style the bullet automatically turn off the native rendering? One thing that I don't like about thinking of the disclosure widget as a list bullet is that it requires the element to have display:list-item. I am not sure how useful it would be to have a summary element be inline or inline-block for example, but I feel like it would be good to support the creation of the ::marker in a manner independent of the display type. But I am drawn to the idea of using list-style-type to specify the plain CSS disclosure widget appearance. It seems natural to me for authors to use list-style-image to supply a custom image.
Re: [whatwg] Styling details
(This isn't the final reply on this thread, but I thought I should give a heads-up as to the general direction I am expecting us to go in here.) On Wed, 6 Apr 2011, Lachlan Hunt wrote: We've been experimenting with the styling of the details element, trying to figure out the most sensible way style it. We have tried to find a solution that behaves the way authors expect, provides for easy restyling by authors and avoiding the troubles associated with magic styles that can't be expressed in CSS. The rendering section of the spec is currently very inadequate and does not describe accurate styles. Also, the sample XBL binding given in the XBL 2.0 draft is also inadequate for a number of reasons. I think the long term solution here is some sort of widget definition binding language like XBL. I don't think it makes sense to do it purely in CSS. Discolsure widgets have all kinds of subtle behaviours like animation during disclosure, hover effects on the triangle, etc. Some systems use a More... or Details... button, some use a triangle, some use +/-. On the short term, I would recommend using the 'icon' property to allow authors to override the icon. I agree that what the spec says is currently inadequate, but without a binding language, I don't think it makes sense to spend time trying to improve it, since any improvement would be a stop-gap measure. The same applies to pretty much all the other form controls. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling details
On Thu, Jul 14, 2011 at 15:21, Ian Hickson i...@hixie.ch wrote: (This isn't the final reply on this thread, but I thought I should give a heads-up as to the general direction I am expecting us to go in here.) On Wed, 6 Apr 2011, Lachlan Hunt wrote: We've been experimenting with the styling of the details element, trying to figure out the most sensible way style it. We have tried to find a solution that behaves the way authors expect, provides for easy restyling by authors and avoiding the troubles associated with magic styles that can't be expressed in CSS. The rendering section of the spec is currently very inadequate and does not describe accurate styles. Also, the sample XBL binding given in the XBL 2.0 draft is also inadequate for a number of reasons. I think the long term solution here is some sort of widget definition binding language like XBL. I don't think it makes sense to do it purely in CSS. Discolsure widgets have all kinds of subtle behaviours like animation during disclosure, hover effects on the triangle, etc. Some systems use a More... or Details... button, some use a triangle, some use +/-. On the short term, I would recommend using the 'icon' property to allow authors to override the icon. Agreed. FYI: http://dev.w3.org/csswg/css3-ui/#icon Feel free to follow-up feedback on that to www-st...@w3.org. I agree that what the spec says is currently inadequate, but without a binding language, I don't think it makes sense to spend time trying to improve it, since any improvement would be a stop-gap measure. The same applies to pretty much all the other form controls. Also agreed. Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] Styling details
On 2011-04-08 23:20, Jukka K. Korpela wrote:
Tab Atkins Jr. wrote:
On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Tab Atkins Jr. wrote:
details is definitely something we want to make fully
author-stylable.
I don’t. Who’s this ”we” you are talking about, and why do they want
to make details author-stylable even before a single browser has
_any_ support to the element, at the functional level?
We being, I suspect, the browser community.
Thank you for the clarification. I would prefer seeing _one_ decent
implementatiom of details before considering any fine tuning.
We, Opera, have an internal implementation. Chrome are also working on
their implementation of it in WebKit. We would like our implementations
to be compatible as far as author styling is concerned, and so it is
very useful to discuss the fine-tuning of CSS styling before we ship.
If we did not do this, then you and every other author would most
certainly complain when Opera and Chrome ship incompatible
implementations that require vastly different approaches to styling.
If that's overreaching,
then I'm content to say that *I* want it to be fully author-stylable,
The primary question, as I see it, is to get decent implementations in
the first place. I don’t see crowds of authors yelling for
author-stylability.
Authors have been yelling for author-styling in relation to many other
elements in the past. In particular, fieldset and legend are
paticularly troublesome because their default appearance and the effect
of applying various CSS properties is literally impossible to express
using CSS or XBL right now, and differnet implementations have slightly
different behaviour in some cases. This severely limits what authors
can do with those elements. Authors have also been yelling for more
ability to style form controls.
As far as details elements are concerned, our developer relations team
at Opera have been discussing these new HTML features with the web
developer community for a long time, and styling is absolutely among the
the top concerns that they pass on to us.
Does it? Why do you imply the visual concept of a ”disclosure
triangle”, and how does that relate to the behavior proposed for
”::marker” in some draft?
I don't understand the question.
Why does details need to have any ”disclosure triangle”?
The default appearance needs a disclosure widget of some kind, either a
triangle or plus symbol or whatever. However, since these default
appearances will not suit all needs, it is essential that authors be
able to change this freely in their pages, which is why we need to
discuss the finer details of how the default styling is defined. This
includes defining suitable 'list-style-type' values for the open and
closed states ('disclosure-open' and 'disclosure-closed'), which authors
may override.
However, the default visual behavior of details is suggested in
the HTML spec.
... And I would not take it as more than a suggestion in a work in
progress, which is what it really is.
Yes, it is a suggestion. But as we are now implementing it, we are
trying to ensure that the spec can be made clearer and more accurate.
I know that many CSS property names are misleading. But
list-style-type, as defined in published CSS recommendations, isn’t
bound to any ”::marker”.
It certainly is, in the Lists spec.
Please cite the recommendation by its official name and/or URL.
http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
Lachlan Hunt wrote: We would like our implementations to be compatible as far as author styling is concerned, and so it is very useful to discuss the fine-tuning of CSS styling before we ship. If we did not do this, then you and every other author would most certainly complain when Opera and Chrome ship incompatible implementations that require vastly different approaches to styling. No, I would not, and when authors start using details, their first concern is, or should be, whether users will recognize the element's rendering as something that provides optional access to detailed information. This usability issue is crucial and should be tested widely, and we need _different_ implementations in order to be able to evaluate different approaches. Authors have been yelling for author-styling in relation to many other elements in the past. Authors yell a lot. You should care more about usability and other aspects of good design than the sounds of authors who are eager to author-style everything. You can't please everyone. Why does details need to have any ”disclosure triangle”? The default appearance needs a disclosure widget of some kind, either a triangle or plus symbol or whatever. It needs to convey the message of optional availability of additional information and an intuitive way of taking the option. It is far from clear how this could best be achieved. As I wrote, we would need to see some implementations before worrying about how to describe them in CSS terms. When (or if) some reasonable implementation approaches will be found, they will most probably need some new features added to CSS. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. It certainly is, in the Lists spec. Please cite the recommendation by its official name and/or URL. http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement The document says: This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. (Markers were in CSS 2.0, and they were dropped out in CSS 2.1. I'm not very optimistic about seeing them well designed and implemented anytime soon.) -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Styling details
On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote: On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: 3. We'd like to get some feedback from web developers, and agreement from other browser vendors, about exactly which glyphs are most appropriate to use for these disclosure states. We considered two alternatives, but we think these three glyphs are the most appropriate. U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE Yup, looks good. FWIW I don't think we need cross-browser agreement here. In particular I think browsers should be free to implement details using a platform-native disclose widget if they like. These are not all alike e.g. OSX uses something like ▸, Windows something like [+] (I think?) and Gnome (at least with the skin I have) something like ▷.
Re: [whatwg] Styling details
James Graham wrote: On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote: On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: 3. We'd like to get some feedback from web developers, and agreement from other browser vendors, about exactly which glyphs are most appropriate to use for these disclosure states. We considered two alternatives, but we think these three glyphs are the most appropriate. U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE Yup, looks good. FWIW I don't think we need cross-browser agreement here. I strongly agree, because agreement on icons would work against the idea of competition and variation between platforms and browsers as well as the idea of platform-wide conventions that users may be accustomed to. On the technical side, the characters proposed are not visually obvious - being regular triangles, they are subject to variation on how they are seen as pointing somewhere. U+25C2, especially in isolation, might be seen as pointing to northeast... Besides, when I first looked at the quoted text, I was using an Android, and all the triangles appeared as replaced by small rectangles. So their font coverage isn't particularly good. In particular I think browsers should be free to implement details using a platform-native disclose widget if they like. These are not all alike e.g. OSX uses something like ▸, Windows something like [+] (I think?) and Gnome (at least with the skin I have) something like ▷. A key issue in making details work for users, and therefore motivating authors into using it, is how to make it as obvious as possible to understand that there is some detailed information available, though currently hidden, and that there is an obvious way to get to it. This is quite a challenge - but to visual designers and usability experts and implementors, not to people who write general specifications. Hopefully, _several_ essentially different experimental (or other) implementations will emerge, will be discussed and tested, and some successful ideas will prevail. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Styling details
On 2011-04-08 11:23, James Graham wrote:
FWIW I don't think we need cross-browser agreement here. In particular I
think browsers should be free to implement details using a
platform-native disclose widget if they like. These are not all alike
e.g. OSX uses something like ▸, Windows something like [+] (I think?)
and Gnome (at least with the skin I have) something like ▷.
Regardless of whether or not we agree on a common glyph to use for this,
we should at least agree on the applicable CSS styles used to achieve
the rendering, which is essential so that authors have an easier time
override them with their own styles.
If we use 'list-style-type', it seems reasonable to at least agree on a
common list-style-type value. Existing list-style-type values in CSS do
define applicable Unicode characters [1], which is why I suggested them.
One option is to define that the list-style-type 'disclosure-*' as magic
values that mean to render a UA specific/platform dependent widget. But
that differs from all other list-style-type values and doesn't seem
quite right.
CSS3-UI, however, uses the 'appearance' property to render native
looking controls.
In theory, native widgets could be achieved instead by using a new
'appearance' value like:
summary::marker { appearance: -x-disclosure; }
(Assuming the 'appearance' value handles the open/close states
automatically, and any animations that would be expected of native controls)
But that would make it slightly harder for authors to restyle as we
don't yet implement ::marker, and won't implement it until we have time
to do it properly for list-items in general (we don't want to a quick
hack just for summary).
Authors would have to do this:
summary::marker { appearance: normal; }
summary { list-style-image: url(...); }
[open] summary { list-style-image: url(...); }
[1] http://dev.w3.org/csswg/css3-lists/#glyph-counters
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On Fri, Apr 8, 2011 at 5:05 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: If we use 'list-style-type', it seems reasonable to at least agree on a common list-style-type value. Existing list-style-type values in CSS do define applicable Unicode characters [1], which is why I suggested them. One option is to define that the list-style-type 'disclosure-*' as magic values that mean to render a UA specific/platform dependent widget. But that differs from all other list-style-type values and doesn't seem quite right. This isn't quite true. The three CSS2.1 bullet styles, for example, are all different on at least one browser. I've specced them specially in Lists such that there is a recommended glyph but browsers are free to use any graphic that's roughly similar. I could easily take a similar approach for the disclosure triangle. ~TJ
Re: [whatwg] Styling details
Lachlan Hunt wrote: Regardless of whether or not we agree on a common glyph to use for this, we should at least agree on the applicable CSS styles used to achieve the rendering, which is essential so that authors have an easier time override them with their own styles. It’s far too premature to consider such things. We don’t know what are the feasible or optimal renderings of details elements. Actually, if you wish to make them widely understood and used, you _don’t_ want to encourage authors to suggest their idiosyncratic renderings. On the average, a web author, left alone, creates a much poorer user interface than a person designing a web browser – simply because the latter is some kind of a professional in such matters. If we use 'list-style-type', it seems reasonable to at least agree on a common list-style-type value. Why should we use list-style-type for something that clearly ain’t no list? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Styling details
On 2011-04-08 18:19, Tab Atkins Jr. wrote: This isn't quite true. The three CSS2.1 bullet styles, for example, are all different on at least one browser. I've specced them specially in Lists such that there is a recommended glyph but browsers are free to use any graphic that's roughly similar. I could easily take a similar approach for the disclosure triangle. OK, that might be acceptable. Though, there are likely to be platform dependent rendering expectations, like hover effects or animations like rotating the triangle when changing from 'disclosure-closed' to 'disclosure-open'. If the spec can make that permissible, then I think that will be acceptable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Styling details
Tab Atkins Jr. wrote: details is definitely something we want to make fully author-stylable. I don’t. Who’s this ”we” you are talking about, and why do they want to make details author-stylable even before a single browser has _any_ support to the element, at the functional level? Why should we use list-style-type for something that clearly ain’t no list? Because it appears that the disclosure triangle wants to have the same behavior that ::marker does. Does it? Why do you imply the visual concept of a ”disclosure triangle”, and how does that relate to the behavior proposed for ”::marker” in some draft? Don't be misled by the name - all that list-style-type does is help construct the default value for 'content' on ::marker. It has nothing to do with things that are semantically lists, per se. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Styling details
On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Tab Atkins Jr. wrote: details is definitely something we want to make fully author-stylable. I don’t. Who’s this ”we” you are talking about, and why do they want to make details author-stylable even before a single browser has _any_ support to the element, at the functional level? We being, I suspect, the browser community. If that's overreaching, then I'm content to say that *I* want it to be fully author-stylable, but I believe Moz feels similarly (Tantek is working on making the form controls more author-stylable). Why should we use list-style-type for something that clearly ain’t no list? Because it appears that the disclosure triangle wants to have the same behavior that ::marker does. Does it? Why do you imply the visual concept of a ”disclosure triangle”, and how does that relate to the behavior proposed for ”::marker” in some draft? I don't understand the question. However, the default visual behavior of details is suggested in the HTML spec. Don't be misled by the name - all that list-style-type does is help construct the default value for 'content' on ::marker. It has nothing to do with things that are semantically lists, per se. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. It certainly is, in the Lists spec. ~TJ
Re: [whatwg] Styling details
Tab Atkins Jr. wrote: On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Tab Atkins Jr. wrote: details is definitely something we want to make fully author-stylable. I don’t. Who’s this ”we” you are talking about, and why do they want to make details author-stylable even before a single browser has _any_ support to the element, at the functional level? We being, I suspect, the browser community. Thank you for the clarification. I would prefer seeing _one_ decent implementatiom of details before considering any fine tuning. If that's overreaching, then I'm content to say that *I* want it to be fully author-stylable, The primary question, as I see it, is to get decent implementations in the first place. I don’t see crowds of authors yelling for author-stylability. Does it? Why do you imply the visual concept of a ”disclosure triangle”, and how does that relate to the behavior proposed for ”::marker” in some draft? I don't understand the question. Why does details need to have any ”disclosure triangle”? However, the default visual behavior of details is suggested in the HTML spec. You misspelled ”the current HTML(5) draft/sketch”. And I would not take it as more than a suggestion in a work in progress, which is what it really is. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. It certainly is, in the Lists spec. Please cite the recommendation by its official name and/or URL. -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Styling details
On Fri, Apr 8, 2011 at 2:20 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: Tab Atkins Jr. wrote: However, the default visual behavior of details is suggested in the HTML spec. You misspelled ”the current HTML(5) draft/sketch”. And I would not take it as more than a suggestion in a work in progress, which is what it really is. I know that many CSS property names are misleading. But list-style-type, as defined in published CSS recommendations, isn’t bound to any ”::marker”. It certainly is, in the Lists spec. Please cite the recommendation by its official name and/or URL. Sigh. I'm not going to respond to you if you're just blatantly trolling. ~TJ
Re: [whatwg] Styling details
On 2011-04-06 02:56, Lachlan Hunt wrote:
To render this, the following CSS should be applied by the UA stylesheet.
detailssummary:first-of-type {
display: list-item;
margin-left: 1em; /* LTR-specific: use 'margin-right' for rtl elements */
list-style-type: -o-disclosure-closed;
}
details[open]summary:first-of-type {
list-style-type: -o-disclosure-open;
}
There are a few other issues that we have identified.
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks
mode, and based on the font-size in standards mode. This is a quirk
implemented by Firefox, IE and Opera for display: list-item; though
WebKit doesn't seem to. We are not sure if this quirk is still required
for web compatibility.
2. If the author attempts to shoot their own foot off by using:
summary { display: none; }
This leaves an empty details box of zero height in the closed state
with no way to open it, and the renders the content without a summary or
disclosure widget in the details open state.
We think this is acceptable, and that we should not introduce the magic
that exists in Chrome's experimental implementation, where they render
the default summary that says Details.
3. We'd like to get some feedback from web developers, and agreement
from other browser vendors, about exactly which glyphs are most
appropriate to use for these disclosure states. We considered two
alternatives, but we think these three glyphs are the most appropriate.
U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE
U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE
U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE
The other alternative we considered was a larger set of triangle glyphs
that were too big for this purpose.
We created a custom SVG font with these glyphs, and I've put up a page
illustrating how each of these look.
http://lachy.id.au/dev/2011/triangle.html
(Use Opera to see the SVG font)
Copies of these glyphs (rendered with list-style-image instead) are now
being used in the simulation I created before.
http://lachy.id.au/dev/2011/details.html
(Check the directory listing there to get all the image files if you
want them.)
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Styling details
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
1. The rendering of details will, unfortunately, inherit the quirks mode
rendering of list-items, where the bullet is a fixed size in quirks mode,
and based on the font-size in standards mode. This is a quirk implemented
by Firefox, IE and Opera for display: list-item; though WebKit doesn't seem
to. We are not sure if this quirk is still required for web compatibility.
You mean that it will inherit that behavior *in quirks mode*, right?
That's not a big deal - old pages won't use details, and new pages
shouldn't use quirks mode.
(Interesting that we don't have that quirk - that probably constitutes
decent evidence at this point that the quirk is unnecessary. I'll try
to remember to file a bug on Gecko about it.)
2. If the author attempts to shoot their own foot off by using:
summary { display: none; }
This leaves an empty details box of zero height in the closed state with
no way to open it, and the renders the content without a summary or
disclosure widget in the details open state.
We think this is acceptable, and that we should not introduce the magic that
exists in Chrome's experimental implementation, where they render the
default summary that says Details.
Yes, I think that's acceptable. The default summary should only show
up if there is no summary element - just hiding the summary element
shouldn't have any special effect. The author's doing it on purpose,
after all. Our implementation is just really buggy.
3. We'd like to get some feedback from web developers, and agreement from
other browser vendors, about exactly which glyphs are most appropriate to
use for these disclosure states. We considered two alternatives, but we
think these three glyphs are the most appropriate.
U+25B8 (▸) BLACK RIGHT-POINTING SMALL TRIANGLE
U+25C2 (◂) BLACK LEFT-POINTING SMALL TRIANGLE
U+25BE (▾) BLACK DOWN-POINTING SMALL TRIANGLE
Yup, looks good.
~TJ
Re: [whatwg] Styling details
On 2011-04-06 03:36, Tab Atkins Jr. wrote:
I like the idea of using display:list-item for thesummary. It has
some unfortunate weaknesses due to the way that display:list-item is
defined; in particular, you can't get an inline summary without losing
the disclosure marker, since there's no way to make an inline
list-item right now.
If authors want to do that now, it's not such a big deal for them to
provide their own disclosure icon as a background image in the padding
area, or to use this in their own styles:
[open]summary::before { content: url(open.png); }
summary::before { content: url(closed.png); }.
I expect this to be fixed on the CSS side in due
time, with the 'display' property split into some subproperties such
that ::marker generation is independent of the list item being inline
or block.
Yes, that will be useful.
I also like the display:transparent idea for handling the wrapper
around the rest of the contents.
:-)
Swapping out bindings (the second solution) feels hacky and bad.
Using a details-specific pseudo-element (the third solution)
doesn't actually solve the problem - it's still a box surrounding the
extra content, so it would suffer from the same problem that was
previous cited, where setting display:table-cell on an element in the
contents wouldn't work as intended. Its only good side is that you
can style the pseudoelement directly, which would make *some*
use-cases salvageable.
Agreed, that's why I said it only provides a workaround, and we are not
taking that approach internally.
Our implementation will be black-box-equivalent to the first two
alternatives, minus the XBL bindings, and our UA stylesheet will be
exactly as I described in the proposed solution.
So either of those approaches should be acceptable, though I do prefer
the more elegant display:transparent; approach.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[whatwg] Styling details
Hi, We've been experimenting with the styling of the details element, trying to figure out the most sensible way style it. We have tried to find a solution that behaves the way authors expect, provides for easy restyling by authors and avoiding the troubles associated with magic styles that can't be expressed in CSS. The rendering section of the spec is currently very inadequate and does not describe accurate styles. Also, the sample XBL binding given in the XBL 2.0 draft is also inadequate for a number of reasons. == Requirements == In designing the solution, we have a number of requirements that we are trying to meet as best we can. 1. The disclosure triangle must be styleable by authors, either to replace with their own icon, remove it entirely, or possibly adjust other common styles. 2. Styling the disclosure triangle should not require complicated hacks with margins, padding or otherwise, to hide the default disclosure icon and replace with a custom icon. 3. The default styles that apply directly to the details and summary elements must be quite simple, such as display, margin and/or padding. 4. The styles applied to the elements in the shadow tree must not have significant adverse effects on the details or summary elements, nor the surrounding content. (We should avoid floating or other styles that may give unexpected results in certain conditions.) 5. If authors change the 'display' style of either the details or summary elements (e.g. inline, table-cell, etc.), the result should be sensible, and not have any unexpected results caused by the styling of the shadow tree. The binding template must not introduce extra whitespace between elements that would affect the rendering in such cases. 6. We cannot require, nor expect, authors to use XBL to restyle these elements. (We aren't actually implementing it with XBL, but we have been discussing it in terms of XBL for future compatibility with it) 7. The content and styling of the shadow tree must not adversely affect the use of ::before and ::after pseudo-elements applied to either details or summary. (Note: Chromium's details implementation has some strange handling for details::before, preferring to render it after the summary instead of before.) 8. The special summary styling, including the placement of the disclosure widget, should only apply to the first child summary element of the details. Subsequent summary elements must not be rendered in unexpected ways. 9. The default action of opening/closing the details should only apply when the user clicks on either the summary text or the disclosure triangle. It should not apply if the user clicks on the other content within the details element. 10. The summary element must be focussable by default and keyboard activation must be possible. The focus ring should be drawn around the summary element and/or the disclosure triangle, and not the entire details element. 11. The disclosure triangle and any applicable margins and padding must render on the opposite side and point the opposite direction for RTL languages. 12. It is preferred to reuse as much existing CSS styles as possible to achieve the effects, avoiding unnecessary creation of special properties or values without a good reason. == Problems with the Spec == *Rendering* There are a number of problems with the way in which the rendering section describes how to render details [2]. When the details binding applies to a details element, the element is expected to render as a 'block' box with its 'padding-left' property set to '40px' for left-to-right elements (LTR-specific) and with its 'padding-right' property set to '40px' for right-to-left elements. The first container is expected to contain at least one line box, and that line box is expected to contain a disclosure widget (typically a triangle), horizontally positioned within the left padding of the details element. According to these requirements, the details element should be rendered something like this: +---+-+ | | Details | | +-| | | The content goes here | +-+ This is analogous to how it works for ul and ol. However, this creates a substantial amount of padding on the left which authors are likely to want to remove or otherwise significantly reduce in most cases. An alternative approach is to apply a small amount of margin or padding to the summary element alone, just enough to render the disclosure triangle within, leaving the remaining content unindented. In this case, a margin or padding of 1em would be a more reasonable size. 40px is too much +---+-+ | | Details | +---+-| | The content goes here | +-+ Note that Chromium's current implementation has an appearance
Re: [whatwg] Styling details
I like the idea of using display:list-item for the summary. It has some unfortunate weaknesses due to the way that display:list-item is defined; in particular, you can't get an inline summary without losing the disclosure marker, since there's no way to make an inline list-item right now. I expect this to be fixed on the CSS side in due time, with the 'display' property split into some subproperties such that ::marker generation is independent of the list item being inline or block. I also like the display:transparent idea for handling the wrapper around the rest of the contents. Swapping out bindings (the second solution) feels hacky and bad. Using a details-specific pseudo-element (the third solution) doesn't actually solve the problem - it's still a box surrounding the extra content, so it would suffer from the same problem that was previous cited, where setting display:table-cell on an element in the contents wouldn't work as intended. Its only good side is that you can style the pseudoelement directly, which would make *some* use-cases salvageable. ~TJ
