Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Thu, Dec 5, 2013 at 5:30 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Dec 2013, Dimitri Glazkov wrote: Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ The key feature here isn't defining _new_ pseudo-elements, but being able to map specific elements in the shadow tree to predefined standard pseudo-elements, in particular, the same pseudo-elements that the standard binding exposes. If such a feature is available, then the HTML spec could list which of the standard pseudos each default binding is expected to expose, and then authors could style subparts of standard controls easily. At least within normal author shadow doms, the intent is to simply document what id/class values users of the component should target for styling. Instead of foo-bar::baz, do foo-bar ^ #baz or similar. Making this work for UA shadows is harder, because we don't want to/aren't able to expose the entire shadow DOM. We can either do magic, or just give up and say that UA-defined controls get to have pseudos without exposing the whole markup tree. ~TJ
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Wed, 04 Dec 2013 16:12:50 -, TJ VanToll tj.vant...@gmail.com
wrote:
The datepicker also shows the problem that using pseudo-elements as
styling hooks presents. The calendars presented on mobile browsers and
desktop browsers are radically different. Even if you wanted to
standardize certain hooks, there is literally nothing in common across
the implementations.
Maybe instead of coming up with one set of pseudo-elements that's limited
to the lowest common denominator we should have multiple completely
different sets of pseudo-elements for each kind of interface?
input::calendar.month-view-grid ::first-week-row {...} // typical desktop
style
input::calendar.spin-wheel ::month-spinner {...} // iOS style
(or any other syntax with cats/hats/dogs/pseudo-functions, as long as it
groups pseudo-elements per kind of calendar UI)
This way developers assuming date pickers are grids with a month view
could style specific pseudo-elements for this layout and mobile browsers
could ignore these styles completely.
--
regards, Kornel
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Fri, Dec 6, 2013 at 2:01 AM, Kornel Lesiński kor...@geekhood.net wrote:
Maybe instead of coming up with one set of pseudo-elements that's limited to
the lowest common denominator we should have multiple completely different
sets of pseudo-elements for each kind of interface?
input::calendar.month-view-grid ::first-week-row {...} // typical desktop
style
input::calendar.spin-wheel ::month-spinner {...} // iOS style
(or any other syntax with cats/hats/dogs/pseudo-functions, as long as it
groups pseudo-elements per kind of calendar UI)
This way developers assuming date pickers are grids with a month view could
style specific pseudo-elements for this layout and mobile browsers could
ignore these styles completely.
And what happens when another implementation comes up with a
completely new interface? Do you want to specify every possible
representation of a date selector? Even if you *intend* only to
specify the (current) most common arrangements, leaving everything
else to its own devices, eventually some author will whine about not
being able to make some implementation fit their precious
meticulously-crafted brand, and it gets all the worse if the
unspecified interfaces *catch on*. The only real solution to this
problem is for authors to accept that they don't have complete control
of the way users view their pages, and that browsers have the freedom
to innovate and develop new interfaces and other features for a
*reason*: to better serve the potentially infinite and contradictory
desires of different users.
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
And Shadow-DOM doesn't let you style an existing control, just fully replace the rendering. So styling a textfield means doing a full editor with all the crappiness that contentEditable pulls in. Yes, a lot of the contentEditable stuff can and should be improved, so possibly this could be as simple as sticking a span contenteditable plaintextonly=true in there one day. Chrome stable now supports replacing the shadow root of input elements, so you can see that this issue in action: http://jsfiddle.net/tj_vantoll/6qadQ/. You can indeed swap Chrome’s native picker with a custom one, but you lose most of the input’s functionality when you do so. Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. The datepicker is a perfect example of this. While developers frequently request the ability to use custom calendars, those same developers want to leave the native mechanism in place for mobile devices. The datepicker also shows the problem that using pseudo-elements as styling hooks presents. The calendars presented on mobile browsers and desktop browsers are radically different. Even if you wanted to standardize certain hooks, there is literally nothing in common across the implementations. Because of this, I don’t think there’s a good way to avoid making developers build their own controls. It’s unfortunate; I just don’t see a way around it. Therefore the main use case I believe needs to be addressed is allowing developers to build a datepicker/colorpicker/etc without reimplementing input. One option that was brought up in #whatwg awhile ago was the ability to create custom form elements. Ideally you could build a datepicker that inherited the behavior of input type=“date”, but gave you the ability to override the way that the data is collected from the user. Perhaps it’s also possible to allow shadow roots of form elements to be replaced without losing the core functionality. TJ
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 10:32 PM, Jonas Sicking jo...@sicking.cc wrote: On Dec 3, 2013 9:39 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements Ah, I thought that the cat and hat combinators had replaced pseudo element support. Glad to see that is not the case. That will probably still happen, at least in the scope of shadow DOM. Cat/hat are a much better replacement. See my (longish) explanation of the problem with custom pseudo elements here: http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0454.html However as the spec is currently written the author still couldn't write a replacement for select which supports a ::options-box pseudo element (if that is what we agree it should be called and what the UA UI should respond to.) Yup. That's something that needs to be figured out. I wonder if the right approach is to explaining pseudo elements is to treat them as something that may rely on Shadow DOM, but is a different beast altogether, because they have some rather interesting quirks (look at ::backdrop, for instance). :DG
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, 3 Dec 2013, Dimitri Glazkov wrote: Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ The key feature here isn't defining _new_ pseudo-elements, but being able to map specific elements in the shadow tree to predefined standard pseudo-elements, in particular, the same pseudo-elements that the standard binding exposes. If such a feature is available, then the HTML spec could list which of the standard pseudos each default binding is expected to expose, and then authors could style subparts of standard controls easily. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Wed, Dec 4, 2013 at 10:30 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Dec 2013, Dimitri Glazkov wrote: Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ The key feature here isn't defining _new_ pseudo-elements, but being able to map specific elements in the shadow tree to predefined standard pseudo-elements, in particular, the same pseudo-elements that the standard binding exposes. If such a feature is available, then the HTML spec could list which of the standard pseudos each default binding is expected to expose, and then authors could style subparts of standard controls easily. FWIW, I got push back on attempting to do this from both Apple and Mozilla at the Shadow DOM CSS Meeting ( http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting). The notes don't do justice, unfortunately ( http://www.w3.org/2013/06/21-webapps-minutes.html (search for SLIGHTLY sympathetic). The gist of the argument was that we should let UAs decide how they want to design controls and avoid limiting their options by standardizing behavior of pseudo-elements. :DG
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Wed, 4 Dec 2013, Dimitri Glazkov wrote: The gist of the argument was that we should let UAs decide how they want to design controls and avoid limiting their options by standardizing behavior of pseudo-elements. I'm not suggesting that we define the actual bindings. Just that we describe some of the components that native bindings might use. For example, a type=number control could have a ::value pseudo and a ::button pseudo, and the ::value would match the text editing area, and the ::button would match the up and down buttons -- except on platforms that replace the whole control with just a text control that pops up a spinner, in which case the ::button wouldn't match anything. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 11:38 AM, Ian Hickson i...@hixie.ch wrote: The real fix is to allow styling formcontrols. It's one of the most requested features from web developers, yet no one has taken the time to research what it would take to do it. Isn't that what Web Components is for? Not at all. However the Shadow DOM spec gets us closer to one approach to it. It lets you replace the rendering of an element with something more complex than what CSS can describe. But there's still no spec that enables you to turn off the native rendering of a form control and just use the normal CSS+Shadow DOM specs to define the rendering. And you still have to use a pile of JS APIs in order to hook up the Shadow DOM. So even something as simple as styling a checkbox as a switch would not be possible to do using just CSS. I.e. developer ergonomics are still worse than a lot of other styling. And Shadow-DOM doesn't let you style an existing control, just fully replace the rendering. So styling a textfield means doing a full editor with all the crappiness that contentEditable pulls in. Yes, a lot of the contentEditable stuff can and should be improved, so possibly this could be as simple as sticking a span contenteditable plaintextonly=true in there one day. But building a full select just because because you wanted to make the list-of-options-box a specific size seems unfortunate. Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. So no. I think we are still very far from stylable form controls. And it's hurting the web a whole lot. / Jonas
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, 3 Dec 2013, Jonas Sicking wrote: On Tue, Dec 3, 2013 at 11:38 AM, Ian Hickson i...@hixie.ch wrote: The real fix is to allow styling formcontrols. It's one of the most requested features from web developers, yet no one has taken the time to research what it would take to do it. Isn't that what Web Components is for? Not at all. Well then we'd better create something that _is_ for this. However the Shadow DOM spec gets us closer to one approach to it. It lets you replace the rendering of an element with something more complex than what CSS can describe. But there's still no spec that enables you to turn off the native rendering of a form control and just use the normal CSS+Shadow DOM specs to define the rendering. With XBL2, that was relatively straight-forward: you just used the 'binding' property, and the binding's shadow tree replaced the element's rendering. Why is it not the same with the Shadom DOM spec? (Also, isn't the Shadow DOM spec part of Web Components?) Anyway, if we don't yet have a good story here, we should write one. It is, as others have pointed out, long overdue. Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. Well, there's not much that can be done about that, as far as I can tell. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. Right. We never developed this very far, but with XBL2 the idea was that we'd eventually let you override the binding of a '::scrollbox' pseudo, or some such. So no. I think we are still very far from stylable form controls. And it's hurting the web a whole lot. I agree it's hurting the Web. I tried to fix this with XBL2, but that never went anywhere. Let's not forget this key use case in the Web components work that is replacing XBL2. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
However the Shadow DOM spec gets us closer to one approach to it. It lets you replace the rendering of an element with something more complex than what CSS can describe. But there's still no spec that enables you to turn off the native rendering of a form control and just use the normal CSS+Shadow DOM specs to define the rendering. With XBL2, that was relatively straight-forward: you just used the 'binding' property, and the binding's shadow tree replaced the element's rendering. Why is it not the same with the Shadom DOM spec? That might actually be the case with Shadow DOM, I might have been misinformed. Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. Well, there's not much that can be done about that, as far as I can tell. Allowing targeting parts of the built-in UI using pseudo-elements would go a long way. I.e. having a ::options-box pseudo-element as well as other pseodu elements for other components of common implementations. This way the UA could ignore the style properties that it can't implement or that doesn't make sense for its UI. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. Right. We never developed this very far, but with XBL2 the idea was that we'd eventually let you override the binding of a '::scrollbox' pseudo, or some such. A scrollbar consists of multiple pieces, so you'll need more pseudo elements. But yes, I think this is the right direction. / Jonas
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, 3 Dec 2013, Jonas Sicking wrote: Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. Well, there's not much that can be done about that, as far as I can tell. Allowing targeting parts of the built-in UI using pseudo-elements would go a long way. I.e. having a ::options-box pseudo-element as well as other pseodu elements for other components of common implementations. This way the UA could ignore the style properties that it can't implement or that doesn't make sense for its UI. Yeah, agreed. Again, with XBL2, the goal was to define some default bindings (in abstract, not concretely) that user agents were supposed to default to, and those bindings would specify pseudos that specific subparts mapped to (XBL2 had an xbl:pseudo attribute for this). You can actually see the remnants of this in the HTML spec's rendering section, where the widgets are defined in terms of the 'binding' property. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. Right. We never developed this very far, but with XBL2 the idea was that we'd eventually let you override the binding of a '::scrollbox' pseudo, or some such. A scrollbar consists of multiple pieces, so you'll need more pseudo elements. But yes, I think this is the right direction. Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Dec 3, 2013 9:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Dec 2013, Jonas Sicking wrote: Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. Well, there's not much that can be done about that, as far as I can tell. Allowing targeting parts of the built-in UI using pseudo-elements would go a long way. I.e. having a ::options-box pseudo-element as well as other pseodu elements for other components of common implementations. This way the UA could ignore the style properties that it can't implement or that doesn't make sense for its UI. Yeah, agreed. Again, with XBL2, the goal was to define some default bindings (in abstract, not concretely) that user agents were supposed to default to, and those bindings would specify pseudos that specific subparts mapped to (XBL2 had an xbl:pseudo attribute for this). You can actually see the remnants of this in the HTML spec's rendering section, where the widgets are defined in terms of the 'binding' property. Defining the list of pseudo elements using a XBL2 binding or using prose is just two was of doing the same thing. So yeah I think either would work. The hard part is coming IP with the list I think. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. Right. We never developed this very far, but with XBL2 the idea was that we'd eventually let you override the binding of a '::scrollbox' pseudo, or some such. A scrollbar consists of multiple pieces, so you'll need more pseudo elements. But yes, I think this is the right direction. Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. I think this is a big problem, so far no one else seems to care. I'd be happy if more people provided this feedback to the spec authors. / Jonas
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Tue, Dec 3, 2013 at 9:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Dec 3, 2013 9:16 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Dec 2013, Jonas Sicking wrote: Additionally, replacing the rendering rather than styling it is hostile towards new platforms. If everyone had used Shadow-DOM to build their own rendering for selects that would have made the transition to mobile much more painful since you'd get a tiny custom select UIs rather than a more platform-appropriate picker. Well, there's not much that can be done about that, as far as I can tell. Allowing targeting parts of the built-in UI using pseudo-elements would go a long way. I.e. having a ::options-box pseudo-element as well as other pseodu elements for other components of common implementations. This way the UA could ignore the style properties that it can't implement or that doesn't make sense for its UI. Yeah, agreed. Again, with XBL2, the goal was to define some default bindings (in abstract, not concretely) that user agents were supposed to default to, and those bindings would specify pseudos that specific subparts mapped to (XBL2 had an xbl:pseudo attribute for this). You can actually see the remnants of this in the HTML spec's rendering section, where the widgets are defined in terms of the 'binding' property. Defining the list of pseudo elements using a XBL2 binding or using prose is just two was of doing the same thing. So yeah I think either would work. The hard part is coming IP with the list I think. And then there's of course the separate-but-related issue of being able to style scrollbars, which is another reason websites create sea-of-divs pages today. The reason this is related is that the challenges styling form controls isn't really related to form controls, but rather related to styling of UA-provided UI. Scrollbars is another such UI. Right. We never developed this very far, but with XBL2 the idea was that we'd eventually let you override the binding of a '::scrollbox' pseudo, or some such. A scrollbar consists of multiple pieces, so you'll need more pseudo elements. But yes, I think this is the right direction. Yeah, the idea is you'd bind to the scroll box to change the whole scroll UI, but you could also then override specific pseudos of the scroll box to style subparts of the default (or custom) scrollbox UI. This part was never very well developed though since the core of XBL2 was never picked up. But I think the same approach should probably still work with the newer Web components work, no? It needs to be specified and implemented... Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-selectors/ :DG
Re: [whatwg] Styling form controls (Was: Re: Forms-related feedback)
On Dec 3, 2013 9:39 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Web components can't define pseudo elements. So no. This sadly also means that you can't write a CSS which styles the default UA UI if that is used, and styles an attached Shadow DOM if that is used. That's simply not true. Where'd you get that? http://www.w3.org/TR/shadow-dom/#custom-pseudo-elements Ah, I thought that the cat and hat combinators had replaced pseudo element support. Glad to see that is not the case. However as the spec is currently written the author still couldn't write a replacement for select which supports a ::options-box pseudo element (if that is what we agree it should be called and what the UA UI should respond to.) / Jonas
