[Imports]: Styleshet cascading order clarification
During our last meeting we all seemed to agree on that defining/implementing order for style-sheets is imports is super hard (if possible) and will bring more pain than it's worth for the web (aka. let's not make an already over-complicated system twice as complicated for very little benefits). And the consensus was that we should just not allow global styles in imports. Some months has passed but I still don't see any update on the spec. in this regard, so I'm just double checking that we still planning to do this or if anything changed since then. - Gabor
New approach to activities/intents
A couple of us at Mozilla have been trying to figure out how to revive activities/intents for the web. Both work relatively well in closed environments such as Firefox OS and Android, but seem harder to deploy in a generic way on the web. What we've been looking at instead is solving a smaller use case. A Sharing API to start and then hopefully reuse the building blocks for other features that need to be liberated. https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. Our thinking is that something like the overlay browsing context could be reused to make e.g. input type=file or save as extensible going forward. However, admittedly it still doesn't really click. It feels a bit too much like e.g. the various search extensions browsers offer. Too much work for little return. Furthermore, freeing the web somehow from closely knitted silos seems like a worthwhile goal, but is often counter to what those silos are interested in. So it might be that we're still not quite there yet, thoughts appreciated. (I put WebApps and TAG on bcc, hope that's okay.) -- https://annevankesteren.nl/
Re: [Imports]: Styleshet cascading order clarification
On Mon, Nov 3, 2014 at 7:28 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: During our last meeting we all seemed to agree on that defining/implementing order for style-sheets is imports is super hard (if possible) and will bring more pain than it's worth for the web (aka. let's not make an already over-complicated system twice as complicated for very little benefits). And the consensus was that we should just not allow global styles in imports. Some months has passed but I still don't see any update on the spec. in this regard, so I'm just double checking that we still planning to do this or if anything changed since then. Out of curiosity, why is it hard? Without much background in the implementation matters, it doesn't seem that a link rel=import that contains a link rel=stylesheet should be any different than a link rel=stylesheet that contains an @import rule. ~TJ
[Bug 27222] New: [Shadow]: title attribute should inherit in shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27222 Bug ID: 27222 Summary: [Shadow]: title attribute should inherit in shadow DOM Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: yky...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 Reference: https://code.google.com/p/chromium/issues/detail?id=420772 The shadow DOM spec doesn't specify how the title attribute works. According to https://html.spec.whatwg.org/#the-title-attribute, the title attribute would not inherit in shadow DOM. It's important that the title attribute inherits in shadow DOM wrt to the composed tree. Currently, it's impossible to create an element with shadow root and set a tooltip on it by setting the title attribute on the host element. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Push API: not a friend of SPDY
Follow-up: there was an issue for meta-data already on the Github. https://github.com/w3c/push-api/issues/81 Please, think of the resources and be webby to one another. Cheerio, rektide On Mon, Oct 27, 2014 at 10:55:40AM -0400, rekt...@voodoowarez.com wrote: Hello. I heard Push is finally in consideration, and having a link put in front of me finally got around to looking- while I'm overjoyed to think the user-agent might expose endpoints, this implementation is however not a friend to SPDY (nor a friend to HTTP); comments, 2: SPDY has push. I'd like to see a Push API that can inform the serviceworker of data pushed via SPDY push. No endpoint registration is required! It's a capability which already exists in every SPDY connection, for which the browser has no corresponding ability to detect the Push. Push already exists, we just don't signal it. Exposing an HTTP server that works as an ingestion endpoint is awesome, it's far more flexible, and far less tightly coupled. This absolutely needs to be another, available form of Push for the user-agent; 100%. But I'd also like to be able to use the push channel that already exists. Please allow SPDY Push to work as a transport in to Push API. Second, why is no header information available in the Push message? Making the client a server but then putting masking tape over the envelope is... un-ethical, brutal, mean, dispirited, breaks things heniously. People are going to send HTTP traffic to it anyways, they're just going to have to wrap/pack unwrap/unpack it, possibly through someone's reverse proxy. For frell sake, expose the headers. The data is going to get there, this is what _is_ going to happen, don't make it a sin of different horrible ways of munging it together. That means you need a little bit more well formed an object for Push message; one that looks like an HTTP request. Might I recommend picking the most harmonious, sensible existing spec out there, such that things generally work rather than making a brand new IDL for Request? The dead-obvious no-effort-required everything-plays-nice developers-don't-laugh-at-you/hate-you-forever options would be to implement (as closely as permittable) the existing spec for an http request- https://fetch.spec.whatwg.org/#request-class I'd point to two previous projects of mine I'd hope Push could help me fully deprecate close the book on- Pipe Layer, a bidirectional asynchronous http over http project, doing an Opera Unite like thing to reverse proxy requests received on the server to the browser) https://github.com/rektide/pipe-layer Pushchannel, which tracks SPDY Push messages and sends X-Associated-Content messages in reply to real resource requests, thereby signalling the user-agent as to the existence of the pushed resources, https://github.com/rektide/pushchannel Alas, if someone wants to push http traffic to ServiceWorker, they'll ahve to pack their messages, often times meaning reverse-proxying through a packing service to achieve interop. WAMP ho, and that's effing horrible crufty ugly dumb and unnecessary. Alas #2, SPDY's push still doesn't signal and is still all but useless as a push mechanism. Whether you will this or you wont, still yours, rektide
Re: [Imports]: Styleshet cascading order clarification
I know this is probably the wrong place/time to say this, but fwiw, a primary use case for imports is replacing: script src=my-lib/my-lib.js/script !-- the script above might have some HTML in it, encoded as a string, comment, or other hack -- !-- the script above may load additional dependencies via some elaborate loader -- link rel=stylesheet href=my-lib/my-lib.css with link rel=import href=my-lib/my-lib.html !-- html and transitive loading all taken care of by imports -- Having the imported stylesheets apply to the main document is a big part of the value here. If the stylesheets are for some other purpose, it's easy to put them in a template, but the reverse is not true. I realize implementation difficulty may trump ergonomics, but I wanted to make sure this part was heard. Scott On Mon, Nov 3, 2014 at 10:12 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Nov 3, 2014 at 7:28 AM, Gabor Krizsanits gkrizsan...@mozilla.com wrote: During our last meeting we all seemed to agree on that defining/implementing order for style-sheets is imports is super hard (if possible) and will bring more pain than it's worth for the web (aka. let's not make an already over-complicated system twice as complicated for very little benefits). And the consensus was that we should just not allow global styles in imports. Some months has passed but I still don't see any update on the spec. in this regard, so I'm just double checking that we still planning to do this or if anything changed since then. Out of curiosity, why is it hard? Without much background in the implementation matters, it doesn't seem that a link rel=import that contains a link rel=stylesheet should be any different than a link rel=stylesheet that contains an @import rule. ~TJ
