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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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;
}
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
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
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
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
33 matches
Mail list logo
