Re: [whatwg] seamless iframes and event propagation
On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Yes, the intent is that in the the events from nodes, distributed to insertion points should feel as if there wasn't any shadow tree around them. Right, but if img is inside the shadow tree (rather than distributed into it), you do not want its load/error events to leak? (Again, it would help if the principles behind those events were written down, e.g. soonish img will start dispatching progress events and who knows what it might dispatch in the future. That list does not address video either if the same would apply to that element.) The basic idea here is that some events, when they are dispatched in a shadow tree, are more likely implementation details that aren't useful outside of this tree. For example, if an img with an image of a volume control loads inside of a video, the author of video definitely doesn't want the corresponding load event to leak out. We could come up with some way to control this via a new API, but beware the growl of complexity bear. So what I want is to tie this into the DOM's dispatch algorithm. The dispatch algorithm somehow needs to compute the ancestor chain and the current plan to do that is to follow an event parent chain (each EventTarget would have an event parent which is either null or some other object). However, it seems that is not quite enough for shadow DOM so instead we need to determine the event parent of an object algorithmically. I think we want event parent for /event type/. So e.g. on ShadowRoot objects the event parent for load would be null, whereas for unicorn it would be its host element. Does that make sense? This logic written down in great detail in Shadow DOM spec -- and tested in an actual browser implementation. Would you consider transplanting it into DOM dispatch? Ian, for HTML that would allow easily dealing with the load exception on Window too. -- http://annevankesteren.nl/
[whatwg] Controlling the UI on input type=date
It is currently difficult to control the visibility of the UI (e.g. little
arrows, spinners, etc) on new input types like datetime, number, range,
color, etc.
It seems that many developers want to use the semantic attributes, but need
to be able to hide the little arrows for various reasons, and so they are
sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897
).
Reasons developers might want to control the visibility of the UI:
- developer has built their own datepicker/numberfinder/colorpicker/etc
- developer wants to display just the values (as if it were type=text) upon
printing, or when readonly, or when not active
As browsers add support, there will likely be ways to control this using
vendor-specific CSS, but not only will this vary from browser to browser,
it will vary among the different input types. For example, in Chrome it is
currently possible to hide the slider arrows on the number input:
input[type=number]::-webkit-inner-spin-button{
-webkit-appearance: none;
}
This kind of code is clearly going to be very difficult to maintain and
keep up to date. I don't think a CSS solution is going to work. Has there
been discussion here on an input attribute that controls the UI? Perhaps
something like this:
input type=date ui=false
Re: [whatwg] Controlling the UI on input type=date
The only thing I've seen in a spec was CSS3 System Appearance, but it had
poor support and was ultimately removed.
2 years ago, I contacted people from Mozilla, Google, Microsoft, and Opera
about this, but I haven't seen any real progress. A few weeks ago, support
for input type=week/month landed in Chrome Canary and this fiddle was
provided to show how to prevent the calendar from showing up:
http://jsfiddle.net/PPpUu/ This is clunky and doesn't even fully solve the
problem.
Here's one of the emails I sent after getting a response about device
vendors wanting to provide consistent UI/UX throughout the device (tying
their native calendar into controls like input type=date):
The problem is that no matter how consistent the UI/UX is, I want to
opt-out because it will never be good enough. I want to customize the UI to
look like my app, layer on additional functionality, etc. All of this is
possible today without the new input types. However, once the new input
types are used, this becomes more difficult. For example, enhancing a text
field into a datepicker is really common, but you can't do this with a date
field because of the new UI. I really don't think that JS implementations
of these input types are ever going to die, no matter how good the native
implementations work. There's just too much functionality that users will
want that won't be possible because the APIs would be too large to spec.
Falling all the way back to text fields works, but then we lose all the
other benefits, such as the new attributes/methods, built-in validation,
type-specific virtual keyboards, etc.
So the end goal is still to have consistent UI/UX cross-browser, but not
necessarily cross-site.
We get a lot of requests for jQuery UI widgets to work on the new input
types. However, as things are right now, all we can do is say no.
On Thu, Dec 6, 2012 at 3:46 PM, brenton strine wha...@gmail.com wrote:
It is currently difficult to control the visibility of the UI (e.g. little
arrows, spinners, etc) on new input types like datetime, number, range,
color, etc.
It seems that many developers want to use the semantic attributes, but need
to be able to hide the little arrows for various reasons, and so they are
sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897
).
Reasons developers might want to control the visibility of the UI:
- developer has built their own datepicker/numberfinder/colorpicker/etc
- developer wants to display just the values (as if it were type=text) upon
printing, or when readonly, or when not active
As browsers add support, there will likely be ways to control this using
vendor-specific CSS, but not only will this vary from browser to browser,
it will vary among the different input types. For example, in Chrome it is
currently possible to hide the slider arrows on the number input:
input[type=number]::-webkit-inner-spin-button{
-webkit-appearance: none;
}
This kind of code is clearly going to be very difficult to maintain and
keep up to date. I don't think a CSS solution is going to work. Has there
been discussion here on an input attribute that controls the UI? Perhaps
something like this:
input type=date ui=false
Re: [whatwg] Controlling the UI on input type=date
On Thu, 6 Dec 2012, brenton strine wrote: It is currently difficult to control the visibility of the UI (e.g. little arrows, spinners, etc) on new input types like datetime, number, range, color, etc. The idea is for Web Components or XBL or some such solution to be the solution to this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
