Re: [webcomponents] Standard Use Case (Was Auto-creating shadow DOM for custom elements)
Let's take a look at the original list of use cases proposed in 2008 at http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases: Layout Manager Layout Manager Use Case Parameters Who Web Framework Engineer What Build a layout library, consisting of a UI layout primitives, such as panel, resizeable panel, tab group, stack, accordion containers, etc. Purpose Allow web application developers to easily build constrained layout and populate it with arbitrary HTML content. Provide a way for developers to build their own layout primitives by extending the provided ones. Examples Dijit Layout GWT Panels Sencha Panels SproutCore Views Desirable Properties Composability -- a method to compose layouts with both UI primitives and DOM elements. Extensibility -- a way to build on layout primitives to create new ones. Encapsulation -- styles, defined to hold layout in place should not be in danger of being stomped on by the author stylesheets. Performance -- layouts built with layout manager should appear quickly, avoiding re-flows and FOUC-like symptoms. Widget Mix-and-Match This use case appears to be satisfied by the existing specifications but only if we use custom elements and shadow DOM together. Mix-and-matching Use Case Parameters Who Web Application Engineer What Build an application using multiple existing controls from several frameworks. Purpose Write application faster by reusing code. Avoid having to exclusively go with one framework. Examples How do you access Dijit elements in JQuery Using SproutCore 2.0 with jQuery UI Which JavaScript framework (jQuery vs Dojo vs … )? Desirable Properties Consistency -- a compatible way to expose properties and methods across widget frameworks. Composability -- a method to compose with cross-framework widgets. Rendering Form Controls with SVG This use case is not satisfied by existing specifications because consistency and composability requirements are not met. SVG Form Controls Use Case Parameters Who Web Application Engineer or Web Framework Engineer What Create a set of UI controls that act like standard HTML forms controls, but use SVG for rendering. Purpose Provide custom appearance of form controls, consistent with overall the Web application theme. Make the form controls scale beautifully for various resolutions and form factors. Examples SproutCore's ImageButtonView, Sencha's Number -- examples of extensive themed form control hierarchy. Desirable Properties Consistency -- the controls should act just like any other DOM elements. Encapsulation -- the document shouldn't be able to accidentally mess up the rendering of the controls. Performance -- load quickly, avoid FOUC-like symptoms when using controls. This use case is probably satisfied by using shadow DOM. Contacts Widge Contacts Widget Use Case Parameters Who Web Application Engineer What Build a drop-in Contacts widget, which has a pre-defined appearance and shows a list of your contacts, with a way to change the widget to compact or full view and to tell the widget to refresh its state. Purpose Use the widget anywhere in the application without having to worry about styles affecting its appearance. Hide details of loading contact data and other plumbing of the widget from the consuming code with a stable API. Examples A screenshot of Google+ in your circles widget Desirable Properties Encapsulation -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget. Composability -- easily added anywhere in the DOM tree. Again, this use case is satisfied only if we used both custom elements and shadow DOM together. Like/+1 Button Like/+1 Button Use Case Parameters Who Web Application Engineer What Build a drop-in widget with a pre-defined appearance of a button, showing a count of likes/+1s for this instance of a button (count is stored at a central location), embeddable on any document on the Web. Purpose Provide a simple vehicle for Web authors to embed the button. Isolate widget implementation details from the document. Examples Facebook Like button embedding instructions Google +1 button embedding instructions Desirable Properties Encapsulation -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget. Confinement -- a way to completely isolate the widget implementation from the document in which it is being embedded. Performance -- don't block the page load. This use case is not satisfied due to confinement requirement. Table-based Charts Table-based Charts Use Case Parameters Who Web Framework Engineer What Provide a way to represent table data markup as charts or diagrams. Purpose Make it easy for Web authors to create charts and diagrams using table markup. Examples Christian Heilmann's tochart script Desirable Properties Composability -- one should be able to make chart by creating a table, imperatively or declaratively. Performance -- no
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Dec 8, 2013, at 12:19 PM, Daniel Freedman dfre...@google.com wrote: Developers want data-binding, and the auto cloning template does not give them a favorable timing model. They want to set those up before the ShadowDOM is stamped, on a per-instance level. If they were to use the automatic template, it would be far too late, and there could be unnecessary network requests or FOUC. Indeed. This is why we've included a data binding feature in our original proposal: http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html We can refine it further to make it more library/framework friendly. In fact, I'm already in contact with Rafael. W. about this. To remove a bit of vaguness from this scenario, Polymer elements use data-binding in almost all cases. Event handlers, computed properties, MVC, everywhere. As such, no Polymer element would use the automatic template registration argument. I doubt that elements created with other libraries like Ember or Angular would make much use of it either. Sure, but that doesn't mean non-framework authors wouldn't use this feature for simple use cases to stamp out the shadow DOM with a static template. However, if some low level data-binding primitives were introduced to the platform, there would be some real merit in an automatic template argument. There would have to be some modifications to the proposal, such as adding hooks for data-binding information to be given to the template instance, but I think those details can be discussed when such a data-binding spec arrives. That seems entirely reasonable, and we're indeed interesting in spec'ing such a feature. Until data-binding primitives arise, I think this automatic template is a premature discussion. Let us spec that automatic template mechanism then. - R. Niwa
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Dec 7, 2013, at 8:33 PM, Rafael Weinstein rafa...@google.com wrote:
On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 3:53 PM, Rafael Weinstein rafa...@google.com wrote:
The issue is that being an element and having shadow DOM -- or any display
DOM, for that matter -- are orthogonal concerns.
There are lots of c++ HTML elements that have no display DOM. Polymer
already has an even larger number.
While that's true in browser implementations, there is very little authors
can do with a plain element without any shadow content it since JavaScript
can't implement it's own style model (i.e. creating a custom frame object in
Gecko / render object in WebKit/Blink) or paint code in JavaScript.
If the only customization author has to do is adding some CSS, then we don't
need custom element hook at all.
I'm was thinking about elements whose purpose isn't presentational. For
example, link or script in html, or polymer-ajax in polymer.
What are advantages of using an element to represent an AJAX request over, say,
doing so in JSON or via function call?
e.g.
Polymer.ajax({url: http://gdata.youtube.com/feeds/api/videos/;, params:
'{alt:json, q:chrome}', handleAs: 'json', onResponse=handleResponse})
instead of
polymer-ajax auto url=http://gdata.youtube.com/feeds/api/videos/;
params='{alt:json, q:chrome}'
handleAs=json
on-polymer-response={{handleResponse}}
/polymer-ajax
It seems strange to have a node in DOM whose sole job is to issue an XHR
request and call a handler.
Having said that, I could imagine people implementing link[rel=import] like
feature using some custom element as a polyfill for a yet-to-be implemented
browser feature.
- R. Niwa
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Tue, Dec 10, 2013 at 9:23 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 8:33 PM, Rafael Weinstein rafa...@google.com wrote:
On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 3:53 PM, Rafael Weinstein rafa...@google.com wrote:
The issue is that being an element and having shadow DOM -- or any
display DOM, for that matter -- are orthogonal concerns.
There are lots of c++ HTML elements that have no display DOM. Polymer
already has an even larger number.
While that's true in browser implementations, there is very little authors
can do with a plain element without any shadow content it since JavaScript
can't implement it's own style model (i.e. creating a custom frame object in
Gecko / render object in WebKit/Blink) or paint code in JavaScript.
If the only customization author has to do is adding some CSS, then we
don't need custom element hook at all.
I'm was thinking about elements whose purpose isn't presentational. For
example, link or script in html, or polymer-ajax in polymer.
What are advantages of using an element to represent an AJAX request over,
say, doing so in JSON or via function call?
e.g.
Polymer.ajax({url: http://gdata.youtube.com/feeds/api/videos/;, params:
'{alt:json, q:chrome}', handleAs: 'json',
onResponse=handleResponse})
instead of
polymer-ajax auto url=http://gdata.youtube.com/feeds/api/videos/;
params='{alt:json, q:chrome}'
handleAs=json
on-polymer-response={{handleResponse}}
/polymer-ajax
I have been wondering this, I've already mentioned that I am not
convinced by having JS and CSS inside an HTML file and using HTML
imports to pull them in.
Hopefully the ES6 module loader can offer an alternative as I think it
can be used to pull in any resource type and with its hooks you can
handle them in the correct fashion.
I'm even less convinced by the notion that custom elements can be
turned into a rerun of Ant.
That holds very little appeal to me, although I'm sure people will
create if else for elements just because they can.
It might just work out this time.
It seems strange to have a node in DOM whose sole job is to issue an XHR
request and call a handler.
Having said that, I could imagine people implementing link[rel=import] like
feature using some custom element as a polyfill for a yet-to-be implemented
browser feature.
- R. Niwa
Re: CfC: publish LCWD of DOM Parsing and Serialization; deadline December 3
On Tue, Dec 3, 2013 at 10:00 PM, Travis Leithead travis.leith...@microsoft.com wrote: [...] I added this serialization step as optional, conditional on the browser storing an internalSubset. It is somewhat upsetting that in 2013 we still need to discuss why optional features and specifications that promote them are bad. I'm willing to have that debate, but I'm quite certain you already know my arguments. So maybe I can ask you to explain why you think it's a good idea. (The same goes for CDATASection obviously.) -- http://annevankesteren.nl/
Call for Exclusions: DOM Parsing and Serialization
Dear Advisory Committee representative, This is a W3C Patent Policy Call for Exclusions for the following Recommendation Track document: - DOM Parsing and Serialization (http://www.w3.org/TR/DOM-Parsing/), exclusion opportunity ending on 8 February 2014 23:59 UTC This specification was produced by the Web Applications Working Group. If you do not wish to exclude patent claims during this exclusion opportunity, no further action is required. Member participants who think their organization may have patent claims to exclude should contact their Advisory Committee Representative. Participants made a Royalty-Free licensing commitment upon joining this Working Group. With the publication of this document, per section 4.1 of the Patent Policy [1], Participants have an opportunity until 8 February 2014 23:59 UTC to exclude patent claims reading on this Last Call draft. At Last Call, exclusions are limited to matter in the Last Call draft that was not present or apparent in this draft: http://www.w3.org/TR/2012/WD-DOM-Parsing-20120920/ Excluded claims are not subject to the licensing requirements of the W3C Patent Policy for this document. For more information about exclusions, please see http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion To make exclusions, please use the following form: http://www.w3.org/2004/01/pp-impl/42538/exclude Summary information for this group related to the W3C Patent Policy is available at: http://www.w3.org/2004/01/pp-impl/42538/status If you have any questions or need further information, please contact, for the Web Applications Working Group: * Yves Lafon at yla...@w3.org For more information on the W3C Patent Policy and patent claim exclusions, see: http://www.w3.org/2003/12/22-pp-faq Thank you, For Tim Berners-Lee, W3C Director; Coralie Mercier, W3C Communications [1] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with [2] http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-resign -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:cora...@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/
Re: Call for Exclusions: DOM Parsing and Serialization
On Tue, Dec 10, 2013 at 3:15 PM, Coralie Mercier cora...@w3.org wrote: - DOM Parsing and Serialization (http://www.w3.org/TR/DOM-Parsing/), There were several outstanding comments against publishing and the WG published anyway? What is going on? -- http://annevankesteren.nl/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Mon, Dec 9, 2013 at 12:42 AM, Dominic Cooney domin...@google.com wrote: You assert that inheriting from built-in elements does not make any sense. You seem to base this on the claim that hooks (the example being form submission protocol hooks) are not well defined. Whether hooks are well defined or not doesn't sufficiently support your assertion, because: 1. Not all subtyping relies on hooks. For example, subtyping a built-in element can add additional API to it. This may make sense. For example, a social network endorse button has a number of additional properties. Yet it is (or could be) a button. 2. The premise that hooks are not defined is also incorrect. Many hooks are already defined. Here is one example: the INPUT element has input and change events and a value property. These are sufficient to observe, filter and change the value of the INPUT element. I think Ryosuke has a point here though. ES6 brings subclassing to the platform, but are not even close to reimagining the platform in terms of that. E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. So I agree with Ryosuke that adding support for subclassing that element would be kind of pointless and potentially harm future endeavors in making it better (as authors might end up relying on it sucking). The other point is well made too. If we want to explain the platform we should not dismiss the bits we don't like about it and point to JS frameworks instead. We should try to explain it, quirks included. -- http://annevankesteren.nl/
Re: Call for Exclusions: DOM Parsing and Serialization
On 12/10/13 10:21 AM, ext Anne van Kesteren wrote: On Tue, Dec 10, 2013 at 3:15 PM, Coralie Mercier cora...@w3.org wrote: - DOM Parsing and Serialization (http://www.w3.org/TR/DOM-Parsing/), There were several outstanding comments against publishing and the WG published anyway? What is going on? During the CfC, I only recall one technical comment and Travis created bug [23936] for that comment and he noted that comment will be considered as a `LC comment`. After the CfC deadline, Ms2ger and James raised a concern about a change in the boilerplate to satisfy the TR publication rules. I created process issues [Issue-71] and [Issue-73] for this concern and I don't think those `general` issues should block the publication. -ArtB [23936] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23936 [Issue-71] https://www.w3.org/community/w3process/track/issues/71 [Issue-73] https://www.w3.org/community/w3process/track/issues/73
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@annevk.nlwrote:
I think Ryosuke has a point here though. ES6 brings subclassing to the
platform, but are not even close to reimagining the platform in terms
of that.
ES6 does not bring sub classing to the table. It has been there all along
(since ES1) and WebIDL heavily uses it.
Maybe I'm missing your point?
E.g. the dialog's close() method won't work as defined
right now on a subclass of HTMLDialogElement.
Why would it not work? Remember that the instance object is going to be a
HTMLDialogElement. Very similar to how people do the __proto__ hack today.
function MyDialog() {
var self = document.createElement('dialog');
self.__proto__ = MyDialog.prototype;
return self;
}
MyDialog.prototype = {
__proto__: HTMLDialogElement.prototype,
};
var el = new MyDialog();
document.body.appendChild(el);
el.close();
The thing that ES6 brings to the table is class side inheritance (doable
today using __proto__) and @@create, which is how the instance is created
so that we don't need the swizzle-proto-return-from-constructor hack.
So I agree with Ryosuke
that adding support for subclassing that element would be kind of
pointless and potentially harm future endeavors in making it better
(as authors might end up relying on it sucking).
The whole point with custom elements is to unify how people create custom
widgets so that YUI, jQueryUI and ExtJS can all share common components,
since the public API is just an Element. If you agree with that goal we
need to at least subclass HTMLElement. Then people want to do the same
thing for SVGElement of course and then we are back were we started.
--
erik
Re: Call for Exclusions: DOM Parsing and Serialization
On Tue, Dec 10, 2013 at 3:42 PM, Arthur Barstow art.bars...@nokia.com wrote: During the CfC, I only recall one technical comment and Travis created bug [23936] for that comment and he noted that comment will be considered as a `LC comment`. It seems the technical comment about it blatantly contradicting the DOM Standard went lost somehow. It's not ready for Last Call. -- http://annevankesteren.nl/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. -Boris
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 3:53 PM, Erik Arvidsson a...@chromium.org wrote: I think Ryosuke has a point here though. ES6 brings subclassing to the platform, but are not even close to reimagining the platform in terms of that. ES6 does not bring sub classing to the table. It has been there all along (since ES1) and WebIDL heavily uses it. Maybe I'm missing your point? ES6 does bring it to the table. Just see how all the methods of built in objects have been carefully redesigned to take advantage of it. We haven't done that on the platform side. -- http://annevankesteren.nl/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. -- http://annevankesteren.nl/
RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
From: a...@google.com a...@google.com on behalf of Erik Arvidsson a...@chromium.org On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@annevk.nl wrote: I think Ryosuke has a point here though. ES6 brings subclassing to the platform, but are not even close to reimagining the platform in terms of that. ES6 does not bring sub classing to the table. It has been there all along (since ES1) and WebIDL heavily uses it. Maybe I'm missing your point? Perhaps the situation is better stated as: ES6 brings a mechanism for creating exotic objects to the table, without opting out of the normal JavaScript meta-object protocol and inheritance model. (Namely, by returning exotic objects from @@create.) Somewhat relatedly, it also brings mechanisms for truly private state via weak maps, which was not possible for non-exotic prototype-using objects before ES6, and finally it allows you to create a large class of exotic objects that you couldn't previously, via proxies. All this means we are now much more capable of expressing WebIDL-derived APIs in terms of the same JavaScript semantics programmers have access to, whereas in the ES5 timeframe only spec-writers and implementers had access to those. As such it is possible to create such APIs that allow subclassing by using these new JavaScript constructs to expose their lifecycle and internals, whereas before they would often simply opt-out of trying to expose a usable JavaScript interface, by e.g. throwing errors whenever people tried to compose them with normal JavaScript concepts like subclassing. The task of retrofitting this kind of support onto the platform is another matter entirely. For example, WebIDL doesn't have an easy way to express `return new this.constructor(...)`---as a subclassing-friendly class would often do---as a result of its declarative type-ish nature. We have had related discussions when defining [Elements][1], and they were never truly resolved. Other places this has cropped up include promises and streams, both of which are designed in subclassing-friendly fashion, but at the price of using ES formalism instead of WebIDL. This is probably just a matter of people putting in the right work to make WebIDL, and the relevant specs consuming it, better. But it's a large task that's still underway. Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). [1]: http://dom.spec.whatwg.org/#collections:-elements
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. -- http://annevankesteren.nl/
RfC: LCWD of DOM Parsing and Serialization; deadline 7 January 2014
This is a Request for Comments for the Last Call Working Draft of DOM Parsing and Serialization: http://www.w3.org/TR/2013/WD-DOM-Parsing-20131210/ If you have any comments, please send them to public-webapps @ w3.org by 7 January 2014. The bugs for this spec are [Bugs]. -Thanks, AB [Bugs] https://www.w3.org/Bugs/Public/buglist.cgi?component=DOM%20Parsing%20and%20Serializationlist_id=30361product=WebAppsWGresolution=---
Re: Call for Exclusions: DOM Parsing and Serialization
On Tue, 10 Dec 2013 17:21:20 +0100, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 4:04 PM, Arthur Barstow art.bars...@nokia.com wrote: Anyhow, if the bug doesn't capture your concern(s), please update it. Since when did we start putting the onus on the reviewer that her or his feedback is captured? Before I started working with W3C in the mid 90's (although as noted below it is part of a set of checks and balances). That seems like the wrong way around. The editor should actively seek feedback and make sure it's tracked and addressed. Indeed. And we expect the editor to do that to the best of their ability. In the past, where editors were actually editing a document that was produced more directly by the whole Working Group, the group itself also assumed some of that function. But editors are not infallible, and the new model Working Group tends to be less hands-on about directing the editor. I believe largely at the perceived behest of a handful of high-profile editors such as yourself. So in practice the necessity for a commenter to check that their comment was understood correctly and correctly acted on has become a little more prominent in the overall balance of how things are done. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. I agree and have previously sketched how large parts of document.register can be made to work with @@create without adding anything to the platform (besides @@create). The things that are still magic are the lifetime callbacks and how the parser first creates the JS objects. We carefully crafted document.register with ES6 classes in mind. It is not a coincidence that both constructor functions and the dict used today ind doc.reg have a prototype property. -- erik
Refactoring SharedWorkers out of Web Workers W3C spec
During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group-should I transplant the Shared Worker spec prose into a separate REC-track editor's document, or simply remove it outright? (Removing it would be easier of course :0) [1] http://www.w3.org/2008/webapps/track/actions/709 [2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 [3] http://www.w3.org/TR/2012/CR-workers-20120501/
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Tue, Dec 10, 2013 at 8:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 3:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 10:34 AM, Anne van Kesteren wrote: E.g. the dialog's close() method won't work as defined right now on a subclass of HTMLDialogElement. Why not? I assumed that actual ES6 subclassing, complete with invoking the right superclass @@create, would in fact produce an object for which this would work correctly. At least any situation that doesn't lead to that is a UA/spec bug. Well for one because the specification at the moment talks about a dialog element and does not consider the case where it may have been subclassed. The pending dialog stack is also for dialog elements only, not exposed in any way, etc. The way the platform is set up at the moment is very defensive and not very extensible. When extending native elements like that you use type extensions, so it'd be dialog is=my-subclass and the tagName is still DIALOG. Registering something that extends HTMLDialogElement but isn't a type extension of dialog does not work, in the same way that doing __proto__ = HTMLDivElement doesn't magically make you into a div today. - E
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On Tue, 10 Dec 2013 20:14:35 +0100, Travis Leithead travis.leith...@microsoft.com wrote: During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group-should I transplant the Shared Worker spec prose into a separate REC-track editor's document, or simply remove it outright? (Removing it would be easier of course :0) And of course, I'd love to see you do the work of putting it into a new spec for the Rec-track, especially if you're able to follow up on editing it. As a chair and personally, I'd love to see someone volunteer to take that work and move it faster than you can... cheers [1] http://www.w3.org/2008/webapps/track/actions/709 [2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 [3] http://www.w3.org/TR/2012/CR-workers-20120501/ -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 10, 2013, at 9:20 AM, Erik Arvidsson a...@chromium.org wrote: On Tue, Dec 10, 2013 at 11:15 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Dec 10, 2013 at 4:10 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Nevertheless, it would be unfortunate to use the in-progress nature of making the web platform more JavaScript-friendly as an argument for making it more JavaScript hostile (by prohibiting element subclassing). Well, the question is more what we should focus on first and whether doing it in the wrong order will be future hostile. I'm also somewhat skeptical that if we don't go through the exercise of explaining a couple of existing elements first, the generic mechanism they are all supposed to end up with will be correct. I agree and have previously sketched how large parts of document.register can be made to work with @@create without adding anything to the platform (besides @@create). The things that are still magic are the lifetime callbacks and how the parser first creates the JS objects. We carefully crafted document.register with ES6 classes in mind. It is not a coincidence that both constructor functions and the dict used today ind doc.reg have a prototype property. Let us look at some examples. http://www.whatwg.org/specs/web-apps/current-work/#dom-document-body says on setting, document.body would in step 3: Otherwise, if the body element is not null, then replace that element with the new value in the DOM, as if the root element's replaceChild() method had been called with the new value and the incumbent body element as its two arguments respectively, then abort these steps. Now, with custom elements, authors can easily override replaceChild's behavior. Yet, UAs will continue to use its internal implementation of replaceChild() for the purpose of this algorithm. If some author is creating an element that inherits from HTMLInputElement like people have been suggesting, then it needs to support every supported types of the input element per Liskov substitution principe to be a proper subclassing. I don't see authors possibly supporting all of the existing types, let alone future types we'll be adding in the future. Now recall our experience with translate content attribute where we broke some JS library made that supported its own version of translate content attribute. With custom elements, authors are encouraged to add similar attributes on subclasses of HTMLElement. It means that anytime we're adding a new property on HTMLElement, we have to be very careful in checking whether a given name is used or not. Allowing subclassing from subclasses of HTMLElement would mean that we're increasing this API surface concern to all of them. That's a lot of new constraints we'll be adding to the extensibility of the Web platform from the browser vendors. Other GUI frameworks and platforms get away with this because those frameworks wouldn't get upgraded automatically. It's true that authors could already do this by modifying the prototype chain of HTMLElement and their subclasses, but that's by no means a natural and encouraged way of programming on the Web today. With custom elements, we'll be encouraging that. - R. Niwa
Re: Refactoring SharedWorkers out of Web Workers W3C spec
We at Mozilla just finished our implementation of Shared Workers. It will be turned on in the nightly releases starting tomorrow (or maybe thursday) and will hit release on April 29th. So if we are only reason we're doing anything here is lack of a 2nd implementation, then we might already be good. That said, I don't know what the test suite status is etc, so I'm totally fine with punting Shared Workers for now. However I'd really like to see us start a level 2 of the spec. The synchronous messaging channels is something else I'd like to see done there. / Jonas On Tue, Dec 10, 2013 at 11:14 AM, Travis Leithead travis.leith...@microsoft.com wrote: During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group—should I transplant the Shared Worker spec prose into a separate REC-track editor’s document, or simply remove it outright? (Removing it would be easier of course :0) [1] http://www.w3.org/2008/webapps/track/actions/709 [2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 [3] http://www.w3.org/TR/2012/CR-workers-20120501/
Re: Refactoring SharedWorkers out of Web Workers W3C spec
On 10/12/13 21:09, Jonas Sicking wrote: We at Mozilla just finished our implementation of Shared Workers. It will be turned on in the nightly releases starting tomorrow (or maybe thursday) and will hit release on April 29th. So if we are only reason we're doing anything here is lack of a 2nd implementation, then we might already be good. That said, I don't know what the test suite status is etc, so I'm totally fine with punting Shared Workers for now. There are certainly some tests for Shared Workers (see [1] and subdirectories), although of course it is always possible to have more tests. [1] https://github.com/w3c/web-platform-tests/tree/master/workers
Re: Refactoring SharedWorkers out of Web Workers W3C spec
As the specification was more written for browser targets I'm not sure if it count for an implementation to you but note that Shared Worker, as well as dedicated workers, are also implemented natively on the server in Wakanda since few versions and often used in this context. see: http://doc.wakanda.org/Workers/Shared-Web-Workers-parent.201-688512.en.html -- Alexandre On 10 déc. 2013, at 22:09, Jonas Sicking wrote: We at Mozilla just finished our implementation of Shared Workers. It will be turned on in the nightly releases starting tomorrow (or maybe thursday) and will hit release on April 29th. So if we are only reason we're doing anything here is lack of a 2nd implementation, then we might already be good. That said, I don't know what the test suite status is etc, so I'm totally fine with punting Shared Workers for now. However I'd really like to see us start a level 2 of the spec. The synchronous messaging channels is something else I'd like to see done there. / Jonas On Tue, Dec 10, 2013 at 11:14 AM, Travis Leithead travis.leith...@microsoft.com wrote: During TPAC 2013 in Shenzhen, I took an action item [1][2] to remove Shared Workers from the W3C Web Workers spec [3] in order for the spec to pass the first of the two stated CR exit criteria in the spec itself. It is my intention to start this work soon. My question for the group—should I transplant the Shared Worker spec prose into a separate REC-track editor’s document, or simply remove it outright? (Removing it would be easier of course :0) [1] http://www.w3.org/2008/webapps/track/actions/709 [2] http://krijnhoetmer.nl/irc-logs/webapps/20131112#l-661 [3] http://www.w3.org/TR/2012/CR-workers-20120501/ Alexandre Morgaut Wakanda Community Manager 4D SAS 60, rue d'Alsace 92110 Clichy France Standard : +33 1 40 87 92 00 Email :alexandre.morg...@4d.com Web : www.4D.com
Re: Styling form control elements
On Sat, Dec 7, 2013 at 11:57 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Jonas Sicking [mailto:jo...@sicking.cc] The reason you've been unable to get rid of the arrow is because it's a separate box that is rendered inside the outermost box. That will remain true even if you use select or select::control to match the outermost box. This is why I believe you want a new pseudo-element to select this separate inner box, so that you can change it's rendering or hide it. I think we have somewhat divergent models of how I'd want to be styling this. More below. Actually, I think our mental models are surprisingly aligned. Which is great! More below. However I'd be curious to see what your UI would look like. Should be easy to do by simply using a DOM like. div class=select div class=optionvalue 1/div div class=optionvalue 2/div /div Would you mind putting together a prototype of what you had in mind? What I had in mind was more like this: div class=select span class=controlvalue 1/span div class=popout div class=optionvalue 1/div div class=optionvalue 2/div /div /div With the browser toggling display: none/display: block on the popout according to OS-specific behaviors. Ah! This is very similar to what I had in mind. I had imagined. div class=select span class=controlvalue 1/span span class=arrowthingy↓/span div class=popout div class=optionvalue 1/div div class=optionvalue 2/div /div /div I.e. exactly the same but with an extra styleable hook for the down array clickable thingy. However using ::after to create such a down arrow seems reasonable. It does make some styling harder, like if you want to have separate borders around the control and the arrowthingy. But arguably that's a shortcoming of CSS and not something we should work around here. So dropping the arrowthingy element seems fine. I was about to give you a sample. I had it 95% done. But then the webpage I was using interpreted a backspace as a Go Back, and when I pressed forward, all my work is lost. So hopefully you can get the idea without me having to re-create that :(. If not let me know and I'll give it another try. Seems fine. I think we're on the same page. Along the way I discovered the following additional needs (eek, scope creep!) I don't think this is scope creep at all. As an implementor, I'm much less interested in implementing a styleable-formcontrols feature that is so minimal that it won't get used, than a more complex, but comprehensive enough solution that it's actually solving people's use cases. - I indeed needed to style the option and the option hover state. option:hover should just work, no? - I needed a way of telling if the parent select was open or not, so that the ::control could stay in a single visual state while the popout was visible, instead of changing as you hovered. I'm not sure I understand this. If you want the ::control to render the same way no matter if the select is open or not, then why do you need to test for that state? I don't mind adding a pseudo-class which only matches if the select is open though. I just didn't understand the use-case. I would also think that you need properties to position the ::popout. XUL used to have a really cool way of allowing you to anchor an element against another element. It would let you select which corner of your positioned element should be aligned to which corner of your anchoring element. Details at [1]. We should be able to do exactly the same thing in CSS as long as we limit it to positioning child elements against their parent elements. We might also need to allow adding an offset as to account for borders and shadows etc. [1] https://developer.mozilla.org/en-US/docs/XUL/PopupGuide/Positioning I agree. But I think this is only part of the problem since often times styling the built-in controls means styling the anonymous elements that are there, not getting rid of them. At least that was my vision. But I agree that C is important too. ... Exactly. So webkit seems closer to C, but still is definitely not C. If you did C there would be no popout at all, and all elements would be rendered directly in the page, no? Right, I think there was a slight miscommunication. For C, I didn't mean nuke all styles on the existing elements, I meant, nuke all styles on the elements and shadow elements, but still expose to me an appropriate set of styleable shadow elements (like ::control and ::popout). That's what B is. I.e. we still keep a few shadow elements around as to enable more rich styling. But we render those style elements using CSS so that they can be fully styled by the web developer. Option C is to nuke all shadow DOM and just render the raw elements. B is already supported in all browsers I tested (didn't test IE). However there's not always pseudo elements that allow you to target the shadow elements. And where there is,
RE: Styling form control elements
From: Jonas Sicking jo...@sicking.cc
Actually, I think our mental models are surprisingly aligned. Which is great!
More below.
Sweet!
So dropping the arrowthingy element seems fine.
I'm not opposed to it, just trying to come up with something minimal.
option:hover should just work, no?
Yeah, but options weren't in my original list, so I wanted to be sure to
include them.
I'm not sure I understand this. If you want the ::control to render the same
way no matter if the select is open or not, then why do you need to test
for that state?
Right, what I meant was: normally, when the select is closed, I want a hover
state for the ::control. But when it is open, I do not want hovering back over
the ::control to do anything visual. So my ideal selectors would be like:
::control {
background: blue;
}
::control:hover {
background: green;
}
select:open ::control:hover {
background: blue;
}
or similar.
I would also think that you need properties to position the ::popout. XUL
used to have a really cool way of allowing you to anchor an element against
another element. It would let you select which corner of your positioned
element should be aligned to which corner of your anchoring element. Details
at [1].
We should be able to do exactly the same thing in CSS as long as we limit it
to positioning child elements against their parent elements. We might also
need to allow adding an offset as to account for borders and shadows etc.
Sounds like a hard part... I think I could get away with letting the UA handle
that for me, at least for now. I.e. ::popout is always below or above control
(depending on how much room is available), according to OS-specific logics. Or
some other position, if I recall Mac OS X selects...
That's what B is.
...
However there's not always pseudo elements that allow you to target
the shadow elements. And where there is, those pseudo-elements are
non-standard.
Ah, that's a more correct way of looking at it; thanks. I was thinking of
appearance: none as a switch that would apply all the way down the shadow tree,
which it clearly doesn't (at least in Firefox; it does seem to in Chrome). As
long as I can nuke that darn Firefox arrow...
Re: Controling style of elements in Injection Points
I've updated your pen with the other minor syntax changes that have occured
in Chrome Canary:
@host - :host
template.content.cloneNode(true) - document.importNode(template.content)
::content p {} will always win over ::content {}, so I moved the black
color to the style for p { }
http://codepen.io/anon/pen/tcjeh
On Tue, Dec 10, 2013 at 2:58 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you all! Finally I understand how it works :)
I made a small pen to illustrate this better
http://codepen.io/dbugger/pen/Hyihd
On 1 December 2013 23:35, Daniel Freedman dfre...@google.com wrote:
::content is behind the Experimental Web Platform Features chrome flag,
along with the unprefixed createShadowRoot.
On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
I have actually have gotten to work with :-webkit-distributed(p) but
as I read it has been deprecated and :content p should work (but it
doesnt).
Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu, in
case it matters.
On 28 November 2013 18:39, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you :) But it is quite confusing to understand how it works. I
have tried to update my example, but still doesn't seem to work. Could you
tell me, in my example, what would be the selector? I tried p::content,
but as you see that doesnt seem to work.
My use case example, again, is here:
http://codepen.io/dbugger/pen/Hyihd
On 28 November 2013 09:58, Hayato Ito hay...@google.com wrote:
Yeah, Chrome has already implemented that. I've implemented that. :)
On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Oh, interesting! Has this been implemented in any browser?
On 28 November 2013 08:46, Hayato Ito hay...@google.com wrote:
We can use '::content' pseudo elements if we want to apply styles to
distributed nodes from a shadow tree.
See
http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element
On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Hello, I have been experimenting with Web Components and I have an
issue, which I think I have represented fairly clear here:
(Tested on Chrome)
http://codepen.io/dbugger/pen/Hyihd
If I understood correctly, one of the points of web components is
to control the presentation of our component. That is why we have the
Shadow Boundary. BUT what happens with the elements that are
represented
with content? They are not considered part of the shadow, therefore
the
styles that the author decides to apply on them, will invade the Web
Component.
Any thought on this?
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
Re: Controling style of elements in Injection Points
And here's yet another version that should be usable in Stable Chrome and
Canary: http://codepen.io/anon/pen/ybEch
On Tue, Dec 10, 2013 at 4:08 PM, Daniel Freedman dfre...@google.com wrote:
I've updated your pen with the other minor syntax changes that have
occured in Chrome Canary:
@host - :host
template.content.cloneNode(true) - document.importNode(template.content)
::content p {} will always win over ::content {}, so I moved the black
color to the style for p { }
http://codepen.io/anon/pen/tcjeh
On Tue, Dec 10, 2013 at 2:58 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you all! Finally I understand how it works :)
I made a small pen to illustrate this better
http://codepen.io/dbugger/pen/Hyihd
On 1 December 2013 23:35, Daniel Freedman dfre...@google.com wrote:
::content is behind the Experimental Web Platform Features chrome
flag, along with the unprefixed createShadowRoot.
On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
I have actually have gotten to work with :-webkit-distributed(p) but
as I read it has been deprecated and :content p should work (but it
doesnt).
Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu, in
case it matters.
On 28 November 2013 18:39, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you :) But it is quite confusing to understand how it works. I
have tried to update my example, but still doesn't seem to work. Could you
tell me, in my example, what would be the selector? I tried p::content,
but as you see that doesnt seem to work.
My use case example, again, is here:
http://codepen.io/dbugger/pen/Hyihd
On 28 November 2013 09:58, Hayato Ito hay...@google.com wrote:
Yeah, Chrome has already implemented that. I've implemented that. :)
On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Oh, interesting! Has this been implemented in any browser?
On 28 November 2013 08:46, Hayato Ito hay...@google.com wrote:
We can use '::content' pseudo elements if we want to apply styles
to distributed nodes from a shadow tree.
See
http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element
On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Hello, I have been experimenting with Web Components and I have an
issue, which I think I have represented fairly clear here:
(Tested on Chrome)
http://codepen.io/dbugger/pen/Hyihd
If I understood correctly, one of the points of web components is
to control the presentation of our component. That is why we have the
Shadow Boundary. BUT what happens with the elements that are
represented
with content? They are not considered part of the shadow, therefore
the
styles that the author decides to apply on them, will invade the Web
Component.
Any thought on this?
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
Re: Controling style of elements in Injection Points
Absolutely brilliant, Daniel! This is very explanatory :) I think I will
write a blog post about this.
Thank you very much for your answer!
On 11 December 2013 00:11, Daniel Freedman dfre...@google.com wrote:
And here's yet another version that should be usable in Stable Chrome and
Canary: http://codepen.io/anon/pen/ybEch
On Tue, Dec 10, 2013 at 4:08 PM, Daniel Freedman dfre...@google.comwrote:
I've updated your pen with the other minor syntax changes that have
occured in Chrome Canary:
@host - :host
template.content.cloneNode(true) - document.importNode(template.content)
::content p {} will always win over ::content {}, so I moved the black
color to the style for p { }
http://codepen.io/anon/pen/tcjeh
On Tue, Dec 10, 2013 at 2:58 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you all! Finally I understand how it works :)
I made a small pen to illustrate this better
http://codepen.io/dbugger/pen/Hyihd
On 1 December 2013 23:35, Daniel Freedman dfre...@google.com wrote:
::content is behind the Experimental Web Platform Features chrome
flag, along with the unprefixed createShadowRoot.
On Fri, Nov 29, 2013 at 6:00 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
I have actually have gotten to work with :-webkit-distributed(p)
but as I read it has been deprecated and :content p should work (but it
doesnt).
Do I need maybe to activate a flag? Im using Chrome 31 under Ubuntu,
in case it matters.
On 28 November 2013 18:39, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Thank you :) But it is quite confusing to understand how it works. I
have tried to update my example, but still doesn't seem to work. Could
you
tell me, in my example, what would be the selector? I tried p::content,
but as you see that doesnt seem to work.
My use case example, again, is here:
http://codepen.io/dbugger/pen/Hyihd
On 28 November 2013 09:58, Hayato Ito hay...@google.com wrote:
Yeah, Chrome has already implemented that. I've implemented that. :)
On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Oh, interesting! Has this been implemented in any browser?
On 28 November 2013 08:46, Hayato Ito hay...@google.com wrote:
We can use '::content' pseudo elements if we want to apply styles
to distributed nodes from a shadow tree.
See
http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element
On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent
enriquemorenot...@gmail.com wrote:
Hello, I have been experimenting with Web Components and I have
an issue, which I think I have represented fairly clear here:
(Tested on Chrome)
http://codepen.io/dbugger/pen/Hyihd
If I understood correctly, one of the points of web components is
to control the presentation of our component. That is why we have the
Shadow Boundary. BUT what happens with the elements that are
represented
with content? They are not considered part of the shadow,
therefore the
styles that the author decides to apply on them, will invade the
Web
Component.
Any thought on this?
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Hayato
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
--
Enrique Moreno Tent, Web developer
http://enriquemorenotent.com
Re: Styling form control elements
On Tue, Dec 10, 2013 at 3:42 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I'm not sure I understand this. If you want the ::control to render the same
way no matter if the select is open or not, then why do you need to test
for that state?
Right, what I meant was: normally, when the select is closed, I want a
hover state for the ::control. But when it is open, I do not want hovering
back over the ::control to do anything visual. So my ideal selectors would be
like:
::control {
background: blue;
}
::control:hover {
background: green;
}
select:open ::control:hover {
background: blue;
}
or similar.
Makes sense. Though technically the user won't generally be hovering
the ::control when they hover the popout. Even if the pixels overlap,
I believe that CSS says that you are just hovering the topmost element
and its ancestors (or maybe that's just what all browsers implement).
However the user could still hover the ::control if it sticks out
under the ::popout.
I would also think that you need properties to position the ::popout. XUL
used to have a really cool way of allowing you to anchor an element against
another element. It would let you select which corner of your positioned
element should be aligned to which corner of your anchoring element. Details
at [1].
We should be able to do exactly the same thing in CSS as long as we limit it
to positioning child elements against their parent elements. We might also
need to allow adding an offset as to account for borders and shadows etc.
Sounds like a hard part...
Hard in what sense? I'd prefer to ask implementors rather than assume
that it's hard for them to implement if that's what you mean. (I can't
speak for the mozilla layout team here).
But I'm fine with postponing this. It seems like something that could
replace piles of JS in many cases, but it's mostly orthogonal to most
of what we're talking about here I suspect.
That's what B is.
...
However there's not always pseudo elements that allow you to target
the shadow elements. And where there is, those pseudo-elements are
non-standard.
Ah, that's a more correct way of looking at it; thanks. I was thinking of
appearance: none as a switch that would apply all the way down the shadow
tree, which it clearly doesn't (at least in Firefox; it does seem to in
Chrome). As long as I can nuke that darn Firefox arrow...
I think it does apply down the tree. I.e. applying appearance: none
to the select also means that the options render without
OS-styling applied.
However it's still not option C which would represent rendering of a tree like
div class=select
div class=optionvalue 1/div
div class=optionvalue 2/div
/div
Which appears not to be what you're asking for.
Though I feel like we're being inconsistent here. It seems arbitrary
that applying appearance: none removes the arrow, but still keeps a
bunch of other styles. Specifically it still keeps the styling that
renders the selected option value, and it keeps the styling that hides
and positions the popout as needed.
I know you hate that arrow, but I'd rather come up with a set of more
generic rules than equating stylable formcontrols with hiding the
arrow ;-)
Potentially the answer could be to say that appearance: css creates
a control rendered entirely using CSS and thus styleable using the
various proposed pseudo elements.
However appearance: none actually renders C, i.e. only the elements
that are in the DOM as described with the markup above. This wouldn't
be useful for a select size=1, but it could be useful for input
type=text or other form controls.
/ Jonas
Re: Styling form control elements
On Dec 6, 2013, at 4:59 AM, Scott González scott.gonza...@gmail.com wrote: On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote: If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. And you'll make the experience worse for many users because many users have devices that you actually don't want to replace. Also, all the other problems about validation, semantics, etc. I've seen this theme pop up for years. There are standards of completeness-- as long as the browser supports a sufficient API, implementers can support complete widgets. The issue is in enumerating and exposing those items which are necessary to construct a widget. We talk about select, well aria has DOM semantics, pseudo-selectors may work for display containers, focus is and has always been mentioned, as well as pointer and keyboard input events within WCAG. We have input method editors for typeahead style select boxes. Now we can shoot all that down and say that the UA should be the only point of control for custom form elements, but that just doesn't create productive discourse. Enumerating and exposing a means to provide a full (Level AAA) custom control is a productive effort. That said, yes, I acknowledge that many controls, UA provided or author created have been and will be substandard. -Charles
Re: Styling form control elements
On 12/10/13 6:30 PM, Jonas Sicking wrote: I would also think that you need properties to position the ::popout. Oh, yes. The extra fun here is: 1) Should the popout be able to paint outside the browser window? Right now, comboboxes (select size=1) can but normal CSS boxes cannot. 2) The popout needs to pop out in different directions (up or down) depending on the screen position of the anchor, the popout dimensions, and the screen dimensions. 3) The size of the popout needs to be capped in some way. Maybe all that logic should just live in the UA and the page just needs a way of saying here is a popout thingie, anchor it here. -Boris
[manifest] HTTP-based solution for loading manifests
Would any potential implementer consider supporting a HTTP based solution to loading manifests? The rationale being: For manifests it is much more commonly going to be the case that there's existing content that people want to add a manifest to. Doing that by editing each and every HTML file or HTML-outputting server side script seems likely to in many cases be much harder than adding a config setting [on the server] that adds a link header. It would mean using something like the HTTP `Link:` header defined in [RCF5988] or a new HTTP header like `Manifest:`. So, something like the following in the case of [1]: Link: /manifest.json; rel=manifest Or the following in the case of a new header: Manifest: /manifest Please see the following for discussion: https://github.com/w3c/manifest/issues/98 [RFC5988] http://tools.ietf.org/html/rfc5988 -- Marcos Caceres
Re: Styling form control elements
On Wed, Dec 11, 2013 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/10/13 6:30 PM, Jonas Sicking wrote: I would also think that you need properties to position the ::popout. Oh, yes. The extra fun here is: 1) Should the popout be able to paint outside the browser window? Right now, comboboxes (select size=1) can but normal CSS boxes cannot. 2) The popout needs to pop out in different directions (up or down) depending on the screen position of the anchor, the popout dimensions, and the screen dimensions. 3) The size of the popout needs to be capped in some way. Maybe all that logic should just live in the UA and the page just needs a way of saying here is a popout thingie, anchor it here. Yes, the popout thingy probably needs to be a specialized 'display' value that is only valid on the popout pseudo, so we can bottle the magic precisely. ~TJ
Re: New manifest spec - ready for FPWD?
Hi Rob, On Wednesday, November 27, 2013 at 9:28 AM, Rob Manson wrote: That's a great overview! There's 2 points I think haven't fully been addressed. 1. Section 8. Navigation Much of this work (and HTML5 in general) is about bringing the Web Platform up to being equal with native apps. But one thing that the Web does that native apps can't do is deep linking (ignoring the fustercluck of intents). I think it would provide a significant advantage if it was also possible to deep link into installed web apps. I understand this is very complex and I'm not proposing any solution right now. But if we don't include this then we are in effect cutting web applications down to the level of native apps instead of leaping ahead of them. Use Case: Social sharing User A and User B both have the same web app installed on the devices they are using. User A finds a resource they like inside the app and decide to share this from within the app through one of their social networks. User B sees this link in their social feed and taps on it. Since User B also has this web app installed it would be nice to be able to open that resource directly within the installed app. Otherwise User X's browser would just open it like a normal web resource. This can also be relevant for the same user using the same web app across multiple devices. NOTE: This is one of the key drivers we have found for building business cases of Web instead of Native. Filed bug to investigate: https://github.com/w3c-webmob/installable-webapps/issues/30 2. Section 6. Start page This is lightly touched on and slightly related to the point above, but the common experience especially on iOS is that even when you background an installed app and then foreground it again it reloads the entire state. This effectively breaks the UX and makes this mode almost unusable. It's definitely possible to use localStorage, etc. to work around this but the UX is horrible. Allowing installed apps to persist their resources and loaded state across background/foreground (and ideally even launches) would be a massive step forward. Perhaps naming this a First use page would help clarify this focus? Agree. This is really evident in iOS at least. Will also investigate if it’s something devs should be dealing with or an OS level thing. At least on iOS, it seems like it’s an OS level thing, as native apps don’t have this problem - you can switch back and force between them (unless they take up massive amounts of RAM, like games… in which case iOS seems to shut down apps as you swap from one to another). Firefox OS seems to fake it by taking a screenshot when the app boots up, which is then used in the task switcher. Tracking this here: https://github.com/w3c-webmob/installable-webapps/issues/31
Re: New manifest spec - ready for FPWD?
On Wednesday, November 27, 2013 at 10:37 PM, Mounir Lamouri wrote: On Wed, Nov 27, 2013, at 8:02, Marcos Caceres wrote: Over the last few weeks, a few of us folks in the Web Mob IG have been investigating the use cases and requirements for bookmarking web apps to home screen. The output of that research is this living document: http://w3c-webmob.github.io/installable-webapps/ That (ongoing) research is helping to inform the manifest spec. A bunch of us have been working together on IRC, twitter, etc. on a new version of the manifest spec: http://w3c.github.io/manifest/ The Editors would appreciate if people take a look and see if you agree with the feature set. The feature set sounds pretty good. I would gladly discuss more why some properties are defined and how some others are but the general gist sounds fine. Maybe some properties should be removed to make things go faster. For example, what's the current support to implement 'mode' and 'dont-share-cookies-and-stuff'? Probably not much… but it’s a thing I want to have in the FPWD for IPR reasons. Will remove it from the living doc till we sort out what it means and how it works. Filed bug for removal: https://github.com/w3c/manifest/issues/105
