| 06:57 | <annevk> | "typical imprecise-DOM-spec-type" lol Domenic, if anything is actually undefined you'll file a bug right? |
| 07:00 | <Domenic> | annevk: yeah... I don't think implementers won't get it, but it's just hard for me to trace when the word "this" is never actually said and it's all so implicit... |
| 07:00 | <annevk> | Domenic: it's not implicit, but if you still think that DOM would handle JS minutia you haven't really been paying attention... that's IDL |
| 07:01 | <Domenic> | annevk: I think "the associated list of event listeners" is pretty implicit. |
| 07:01 | <Domenic> | associated to what? |
| 07:03 | <annevk> | If used as mixin that might be unclear I guess |
| 07:03 | <annevk> | File a bug? Is it used as mixin anywhere? |
| 07:03 | <Domenic> | Or when it's on the prototype chain, especially when window vs. window proxy is involved. |
| 07:03 | <Domenic> | nah as i said i'm sure implementers are fine with it |
| 07:04 | <Domenic> | just not the level i'm used to |
| 07:04 | <annevk> | I don't see how WindowProxy matters here. No events are ever dispatched at it. |
| 07:04 | <Domenic> | consider `window.addEventListener("foo", ...) |
| 07:05 | <Domenic> | That invokes the method with `this` set to the WindowProxy, not to the Window |
| 07:05 | <Domenic> | Does WindowProxy have an associated set of event listeners? |
| 07:05 | <annevk> | I don't think so, it's not an EventTarget object either |
| 07:06 | <Domenic> | Why isn't it? Is there any test you could run on it that would allow you to say that it is not? |
| 07:06 | <annevk> | There's an open bug on IDL to define "this" and pass it on more clearly |
| 07:07 | <Domenic> | And if it doesn't have an associated set of event listeners, then how does addEventListener get "the" associated set of event listeners to operate on? |
| 07:07 | <annevk> | That might be a problem with the definition of Window/WindowProxy, sure |
| 07:08 | <annevk> | At this point DOM doesn't really have anything on those objects |
| 07:08 | <Domenic> | Well my point was more that if you said "the [[Events]] internal slot of `this`" then it would be much clearer what the answers to those questions are |
| 07:10 | <annevk> | Domenic: that is the defined behavior through "context object", for which I already mentioned that we asked IDL to make it explicit, at which point I'll probably start using it explicitly rather than omit it for brevity when it's clear from context |
| 07:11 | <annevk> | Domenic: I don't necessarily disagree with using slots instead, there's an open IDL bug on that too |
| 07:11 | <annevk> | Domenic: but that things are not defined in language you prefer doesn't make it imprecise, that would mean implementers could reach different conclusions from the same text at which point they'd file bugs etc. |
| 07:13 | <Domenic> | I think implementers could legitimately reach different conclusions about what "the associated set of event listeners" means in the context of window vs. window proxy |
| 07:13 | <Domenic> | And about the question of whether WindowProxy is an EventTarget object |
| 07:14 | <Domenic> | Anyway I didn't mean to pick a fight right before I had to sleep. More just was putting that there as a disclaimer that I might not be reading things right. |
| 07:14 | <annevk> | But why then claim that the DOM specification is unclear when it is in fact the specification for WindowProxy that is sorely lacking as we all already know? |
| 07:14 | <Domenic> | or at least, not reading things as they are intended |
| 07:15 | <Domenic> | I think the DOM spec could be made clearer independent of window vs. window proxy. Proxies are pretty well-defined behavior. |
| 07:15 | <Domenic> | "the associated set" is not well-defined. |
| 07:15 | <annevk> | It's the context object's associated set |
| 07:15 | <annevk> | So if the context object is WindowProxy as you say, that would be it |
| 07:16 | <Domenic> | I mean the definition of context object isn't exactly that clear either |
| 07:16 | <Domenic> | "on which something is being called" |
| 07:16 | <annevk> | That is fair, and as I said I'm waiting for an IDL fix |
| 07:16 | <annevk> | Because only IDL can set that parameter correctly based on the JS -> IDL -> spec -> IDL -> JS bridge |
| 07:17 | <Domenic> | Anyway, I need to head to sleep, sorry for the offhanded comment :-S |
| 07:26 | <zcorpan> | why is cssom access restricted to same-origin again? |
| 07:27 | <annevk> | zcorpan: euh, web security model? |
| 07:29 | <zcorpan> | annevk: you can get the computed style so the declarations leak anyway, and you can't get the original text since it's parsed and reserialized, so you can't read things that are not css |
| 07:30 | <annevk> | zcorpan: declarations of styles not applied don't leak, declarations of styles not applied depending on cookies don't leak, etc. |
| 07:31 | <zcorpan> | annevk: so having a secret in a selector |
| 07:34 | <annevk> | zcorpan: are we requiring text/css as MIME type these days? If servers can be tricked into using that MIME type for resources there might be other risks too |
| 07:35 | <zcorpan> | annevk: yes, except in quirks mode but that's only for same-origin stylesheets |
| 07:35 | <annevk> | zcorpan: we should not reduce the amount of protection the same-origin policy gives, the amount that CSS, images, and script leak today is sufficient |
| 07:36 | <annevk> | (well, too much really) |
| 07:36 | <zcorpan> | annevk: sure, i agree |
| 07:45 | <zcorpan> | i remember https://bugzilla.mozilla.org/show_bug.cgi?id=524223 but it didn't use cssom |
| 08:02 | <annevk> | zcorpan: that CSS loads across origins is a bug, restricting CSSOM is to some extent defense-in-depth and to some extent actually defends out-of-scope declaration blocks |
| 08:13 | <zcorpan> | annevk: thanks. https://lists.w3.org/Archives/Public/public-houdini/2015Feb/0053.html |
| 08:33 | <annevk> | zcorpan: don't we support CORS now for CSS loads? |
| 08:34 | <zcorpan> | annevk: the spec does, don't remember what is implemented |
| 08:35 | <annevk> | zcorpan: the other thing this is protecting of course is what CSSOM might become going forward; it would seem bad to forever constrain yourself by the current invariants |
| 08:36 | <zcorpan> | yeah |
| 08:37 | <annevk> | zcorpan: also, getComputedStyle requires brute-forcing to find all selectors as there's no other way to read them |
| 08:37 | <annevk> | zcorpan: coupled with varying media somehow, etc. |
| 08:38 | <annevk> | zcorpan: raw CSSOM exposes all trivially |
| 08:38 | <zcorpan> | yeah but it's still pretty trivial to do |
| 08:38 | <zcorpan> | varying media is more annoying |
| 08:54 | <Krinkle> | I'm not a 100% sure but I think I've seen some user extensions make use of CORS and CSS at Wikimedia. |
| 08:54 | <Krinkle> | To be able to inspect the loaded rules from a no-cookies domain |
| 08:57 | <annevk> | zcorpan: it would take quite some time |
| 09:01 | <zcorpan> | annevk: i'm writing a testsuite for the rendering section that basically does exactly this. i'm even checking :before and :after on each element. it's not taking that much time |
| 09:03 | <annevk> | zcorpan: euhm, you also need to generate all possible trees |
| 09:07 | <zcorpan> | annevk: yeah that will take infinite time, but you probably can get far by enumerating the most commonly used elements, classes and ids |
| 09:14 | <oenftw> | good morning, are there any benefits of using the HTML5 semantics? |
| 11:59 | <annevk> | zcorpan: maybe, but you'll get more with CSSOM which seems bad |
| 11:59 | <zcorpan> | annevk: yes |
| 15:14 | <aleray__> | hi, is it ok to use h1 inside <article> tags? |
| 15:15 | <annevk> | aleray__: yes |
| 15:15 | <aleray__> | annevk,thanks |
| 15:15 | <aleray__> | I had contradictory readings about that. |
| 15:16 | <annevk> | I think the model suggested by the specification does not have full support, which is why people might caution against it as a practical matter |
| 15:16 | <aleray__> | This text suggests the following for instance: http://html5doctor.com/the-article-element/ |
| 15:17 | <aleray__> | in the "An <article> with comments as nested <article>s" section |
| 15:18 | <annevk> | aleray__: they don't recommend against it though, do they? |
| 15:18 | <annevk> | aleray__: they just have a header for the article rather than just a heading |
| 15:19 | <annevk> | aleray__: and actually, under "Using <article> for a widget" it seems to cover the case of using <h1> directly |
| 15:21 | <aleray__> | annevk, ok. Not sure to understand the subtlety. I will go through it again. In my case I have a div in which I list news. Each news is wrapped in an <article> and now has an h1 in it. |
| 15:21 | <annevk> | aleray__: sounds fine |
| 15:23 | <aleray__> | annevk, nice. My outline is wrong but I might have unclosed tags somewhere. Let's fix the structure first |
| 15:24 | <aleray__> | btw, just fyi I have just published https://github.com/aleray/html5lib_typogrify |
| 15:25 | <aleray__> | it is really minimal now, but if I have time I will expand it |
| 16:22 | <annevk> | JakeA: what does GPU-rendered DOM element mean? |
| 16:22 | <Ms2ger> | Nothing |
| 16:23 | <JakeA> | annevk: do the rasterisation on the GPU, like we do with canvas right now |
| 16:23 | <annevk> | JakeA: I think the main slowness people have with DOM, across both React and the Google components crowd, is that if you have a large mutating tree, layout gets slow. Both then take the approach of putting all the data outside the DOM and then stamping out something smaller based on what is seen by the user through a template of sorts... |
| 16:24 | <annevk> | JakeA: so that instead of a 10000 item list, you only have a list with 50 items that are seen by the user, backed by a 10000 item JavaScript array |
| 16:25 | <annevk> | JakeA: unless we can solve that scenario, the DOM seems rather doomed as information container |
| 16:26 | <JakeA> | annevk: wouldn't some layout feature make that ok in the DOM? Some kind of list-view display? I guess you could do that yourself with hooks into layout |
| 16:26 | <annevk> | JakeA: so this GPU-rendering of DOM elements is GPU-rendering of CSS "boxes"? |
| 16:26 | <Ms2ger> | xul:listbox |
| 16:27 | <annevk> | JakeA: well, what Polymer has is <core-list>, which has this JavaScript-backed thing |
| 16:27 | <JakeA> | annevk: Yeah |
| 16:27 | <annevk> | JakeA: ok that makes more sense |
| 16:29 | <annevk> | JakeA: a layout primitive goes some ways, though does not necessarily help with invalidation of trees due to mutation and selectors that then have to match again |
| 16:29 | <annevk> | JakeA: for that isolated styles could help |
| 16:29 | <annevk> | JakeA: wycats has some ideas around that, but nothing concrete |
| 16:30 | <annevk> | But it's a rather large gap to bridge and I can totally understand why we have these experiments going on to get it some other way |
| 16:32 | <annevk> | JakeA: anyway, this has annoyed me too, thanks for pushing people to dig a little deeper |
| 16:39 | <wycats> | annevk: which ideas? |
| 16:40 | <wycats> | JakeA: the biggest issue with list-view is the lack of scroll hooks |
| 16:40 | <wycats> | https://github.com/emberjs/list-view is used a lot in production Ember apps |
| 16:40 | <smaug____> | Ms2ger: I think you want xul:tree |
| 16:41 | <JakeA> | wycats: Chrome has been proposing a sync scroll handler (onbeforescroll) but I think it's getting push-back from other vendors |
| 16:41 | <annevk> | wycats: around isolation for CSS |
| 16:41 | <wycats> | JakeA: yeah |
| 16:41 | <wycats> | JakeA: I think we should provide it and accept that it forces us to think hard about keeping frames small |
| 16:41 | <JakeA> | annevk: yeah, I guess we need style resolution hooks and/or isolation |
| 16:42 | <wycats> | JakeA: Shadow DOM helps a lot here |
| 16:42 | <wycats> | especially for list views |
| 16:42 | <wycats> | unrelatedly, I just posted: https://twitter.com/wycats/status/569893045321101312 |
| 16:42 | <JakeA> | wycats: agreed. Maybe sync handlers are bad but all the touch-event-based scroll reimlementations are way worse |
| 16:42 | <annevk> | JakeA: there's interest from Mozilla in solving the problem, though roc seems to prefer adding a UI-centric worker |
| 16:43 | <wycats> | JakeA: 100% |
| 16:43 | <annevk> | JakeA: see dev.platform thread I pointed to on Twitter |
| 16:43 | <wycats> | annevk: I need to speak to roc |
| 16:43 | <wycats> | I don't agree with him on that thread |
| 16:43 | <wycats> | (as a person who has implemented this stuff) |
| 16:43 | <wycats> | I don't mind creating a new UI daemon |
| 16:43 | <wycats> | but it's not tackling the problem head-on |
| 16:43 | <JakeA> | wycats: I think there are some oddities that make that not true. Maybe position:fixed inside that element? I can't remember. TabAtkins would know. |
| 16:43 | <annevk> | wycats: give it three-four hours and he might be online I guess, assuming he's at home |
| 16:44 | <wycats> | :) |
| 16:44 | <wycats> | the way to tackle the problem is to look at the 17ms timeslice, figure out where it's going, and figure out how to shrink it |
| 16:44 | <wycats> | and then figure out how to give developers APIs that don't blow the budget |
| 16:44 | <wycats> | people who are writing things like list-view are very very very good devs |
| 16:44 | <wycats> | they can color inside the lines if they had the tools |
| 16:46 | <jgraham> | annevk: You got time to look at https://critic.hoppipolla.co.uk/r/3216 ? |
| 16:46 | <annevk> | JakeA: btw, the DOM spec calls it the "node tree" if you want a different term |
| 16:46 | <annevk> | JakeA: https://dom.spec.whatwg.org/#node-tree |
| 16:47 | <annevk> | JakeA: the JavaScript community sometimes uses "DOM" as a term for everything not JavaScript, which has been confusing me at times |
| 16:48 | <JakeA> | annevk: node tree is a good name for it |
| 16:48 | <JakeA> | nice |
| 16:51 | <annevk> | https://twitter.com/getify/status/569902233262796800 lol who exactly has been swapping terms :p |
| 16:52 | <Ms2ger> | "DOM layout"? |
| 16:53 | <Ms2ger> | As opposed to what? |
| 16:54 | <annevk> | JakeA: if you haven't seen it, I recommend looking at https://speakerdeck.com/vjeux/react-css-in-js |
| 16:54 | <annevk> | JakeA: it's a really great introduction to everything that is wrong with CSS |
| 16:55 | <boogyman> | annevk: i would argue that understand the meaning of DOM is much more important than knowing the word-for-word translation of the acronym, which may be what you're all eluding to in the proposed "rename/remap". |
| 16:55 | <annevk> | boogyman: what is the meaning? |
| 16:57 | <boogyman> | In Kyle's tweets it appears he's pushing back against DOM meaning "Node Tree" or "Document Model Model" or whatever "DOM layout" means. |
| 16:58 | <annevk> | boogyman: yeah, as I said above that's fairly prevalent in certain circles, Kyle's claim it goes for all web developers I doubt, but it's common |
| 16:58 | <jgraham> | I've for-sure seen people say "DOM is slow" when they meant "some aspect of CSS/layout is slow" |
| 16:59 | <jgraham> | e.g. someone complaining that adding flexbox to 50 elements caused slowness that they could avoid by computing absolute positions for those elements |
| 17:03 | <boogyman> | Understand the point, but "computing abs.pos." tells me they are only targeting small set of the world, which in itself is not ideal. |
| 17:04 | <wycats> | annevk: I think there are better solutions than vjeux's |
| 17:04 | <wycats> | Ember is investigating ;) |
| 17:05 | <wycats> | but his articulation of the problem is good |
| 17:05 | <jgraham> | Right, it might be that the new thing they did was a terrible mess. But they piggybacked on the "DOM is slow" meme to air a complaint about a facet of the platform that is entirely unrelated to the DOM. |
| 17:05 | <wycats> | jgraham: confirm |
| 17:06 | <wycats> | also, most of the platform is tractabl |
| 17:06 | <jgraham> | So even if we solve the problem, people will go "oh, there's still a DOM so it's still going to be too slow" |
| 17:06 | <wycats> | even within the context of the existing programming model |
| 17:06 | <wycats> | I am pretty tired of the revolutionaries |
| 17:06 | <wycats> | "let's replace CSS with a constraint solver" |
| 17:06 | <wycats> | "let's replace CSS with inline styles" |
| 17:06 | <wycats> | etc. |
| 17:09 | <wycats> | I would be happy with identifying portable style boundaries and specifying them |
| 17:10 | <wycats> | and also identifying easy heuristics you can use to prune selectors you don't have to match for a given operation |
| 17:13 | <gsnedders> | CSPs are really easy to solve, though! |
| 17:13 | <gsnedders> | BUT WHAT CSP AM I REFERRING TO?! #OverloadedInitalismsAreFun |
| 17:20 | <Ms2ger> | The common salesman problem? |
| 17:24 | <jsx> | In @counter-style, <symbol> = <string> | <image> | <ident> |
| 17:24 | <jsx> | What would be an example for <ident> |
| 17:24 | <Ms2ger> | blah |
| 17:49 | <annevk> | wycats: yeah, not sure about the solution space, but mostly the "this is a problem and why" is really good and interesting |
| 17:50 | <annevk> | wycats: heh, there's a bit of XHTML 2.0 in everyone :p |
| 17:51 | <gsnedders> | Ms2ger: no, Communicating Sequential Processes, duh! |
| 19:10 | <wycats> | lol |
| 19:21 | <jamesr___> | wycats: you need position as well, i believe |
| 19:23 | <jamesr___> | wycats: or positioned descendants of the overflow:hidden things will influence the position of siblings |
| 19:24 | <jamesr___> | ah, i see this was already covered on twitter |
| 19:24 | <gsnedders> | jgraham: should we make the tree walker tests part of the parser tests? I mean they're guaranteed to fail if the identical parser test fails… |
| 19:24 | <gsnedders> | jgraham: so it seems kinda like they should be part of the same test |
| 19:30 | <wycats> | is position: relative sufficient? |
| 19:54 | <roc> | wycats: speak to me |
| 20:17 | <wycats> | roc: I am currently pair programming on Ember |
| 20:17 | <wycats> | but I will ping you when I have uno momento |
| 20:21 | <TabAtkins> | jsx: Hm, it's linking over to the wrong spec for <ident>, but that just means keywords. |
| 20:30 | <roc> | annevk: that css-in-js deck is nowhere near "everything that's wrong with CSS" :-) |
| 20:31 | <roc> | in fact, I quite like their approach of driving everything with JS and inline styles. I was just thinking recently that that seems like a good way to negate one of the performance issues of Web vs native --- selector matching and cascading |
| 20:36 | <TabAtkins> | Yeah, I think there's some really interesting ideas we can dig out of there for applying styles more locally. |
| 20:36 | <TabAtkins> | Rather than the big mishmash of global styles that CSS is today. ^_^ |
| 20:37 | <annevk> | roc: haha, fair |
| 20:38 | <annevk> | roc: yeah, the tight coupling is really interesting, also how useless specificity is |
| 20:38 | <roc> | the deck kinda oversells "CSS in JS" though |
| 20:39 | <annevk> | Might be because React has that approach to all the things that are not JS |
| 20:39 | <roc> | they're not bypassing all of CSS, not by any means --- just part of the style system |
| 20:39 | <TabAtkins> | I'm almost certain that a mature version of that would reinvent some form of specificity, though. You could probably get away with just a single explicitly-supplied number, though. |
| 20:39 | <TabAtkins> | Without it, you have to rely on temporal ordering of application, which is trickier to manage as you get more complex. |
| 20:40 | <annevk> | TabAtkins: yeah, I guess you want some of it, coupled with isolation it wouldn't be an issue |
| 20:40 | <Domenic> | roc: I think they are bypassing hte "cascading" and "sheets" parts of CSS :P |
| 20:41 | <roc> | Domenic: yeah, well, it turns out that despite the naming, most of CSS is actually not about that :-) |
| 20:41 | <TabAtkins> | I want to spend some time later this year thinking about this some more, and seeing what I can come up with. More experiments in this area by the JS people will help. |
| 20:41 | <roc> | I don't think stylesheets are really helpful to people building these apps |
| 20:41 | <annevk> | TabAtkins: I expect that not solving this will halt work on shadow DOM and such as well |
| 20:42 | <TabAtkins> | Agreed; they're actually an anti-feature when you're trying to get composability. |
| 20:42 | <TabAtkins> | annevk: yup. |
| 20:42 | <annevk> | TabAtkins: maybe less so for custom elements |
| 20:42 | <roc> | when you're constructing lots of DOM nodes with JS, it makes sense to set style values explicitly from JS as well. |
| 20:42 | <annevk> | TabAtkins: but I'd like to see us sort out what the way forward is for React / Ember style applications before committing to shadow DOM |
| 20:43 | <annevk> | Maybe Bert Bos was right after all that you don't want HTML/CSS/JS for applications |
| 20:43 | <TabAtkins> | No, he was still wrong, because what you want is just JS. ^_^ |
| 20:44 | <annevk> | I may have remembered http://www.w3.org/People/Bos/webapps.html and http://www.w3.org/People/Bos/webapps-proposal.html for more than they are |
| 20:44 | <annevk> | TabAtkins: heh |
| 20:46 | <roc> | I like having a proper mental image of Tab to associate with his messages |
| 20:46 | <TabAtkins> | roc: Same! |
| 20:46 | <roc> | still don't have Domenic :-( |
| 20:47 | <TabAtkins> | His Twitter image is accurate. |
| 20:47 | <roc> | by "image", I don't mean an image :-) |
| 20:52 | <annevk> | roc: do you have some data on how long the selector matching takes vs other parts of CSS? |
| 20:54 | <roc> | I don't, but it's definitely enough that people (in Gecko and Blink at least) spend a ton of work optimizing it |
| 20:56 | <roc> | e.g. we did some work a while back to ensure that modifying inline style rules doesn't require rerunning selector matching. That helped some cases a lot. |
| 20:56 | <wanderview> | roc: is this the motivation for scoped styles as well? seems they have not worked out |
| 20:56 | <wanderview> | explicit inline styling being the extreme case of "scoped" styles |
| 20:58 | <roc> | wanderview: no. Scoped styles are a modularity mechanism. |
| 20:58 | <wanderview> | ok |
| 20:58 | <roc> | and actually quite a helpful one, I think. It's just that Blink chose not to implement them |
| 20:59 | <roc> | same for CSS variables |
| 20:59 | <wanderview> | just seemed it would reduce the node tree that could be selector matched |
| 20:59 | <roc> | yes, that it does, though I don't think we've fully optimized around that |
| 21:00 | <annevk> | does it? external selectors could still match |
| 21:00 | <annevk> | there's no isolation |
| 21:00 | <wanderview> | annevk: I meant for styles modified in the "scoped" style tag |
| 21:01 | wanderview | only understands about 5% of this stuff... |
| 21:04 | <roc> | annevk: changes to the DOM outside the scope can't change the results of selectors in the scoped styles |
| 21:04 | <annevk> | wanderview: hmm fair, I think the bottleneck is DOM mutations, but I don't actually know |
| 21:05 | <annevk> | roc: also fair |
| 21:05 | <annevk> | roc: I think Chrome killed variables because their code wasn't up to par, not because they don't want the feature |
| 21:06 | <roc> | that sounds harsh ... but yes |
| 21:06 | <annevk> | roc: <style scope> seemed more adversarial and had to do with shadow DOM, something we're not quite sure about |
| 21:06 | <annevk> | roc: heh, maybe I misremembered but I thought that's what they said on blink-dev |
| 21:07 | <jamesr___> | that seems accurate from what i remember |
| 21:10 | <wanderview> | roc: I like your distinction about applying styles manually to elements... that's essentially what a programmatic native UI API would do... vs CSS declarative usage |
| 21:11 | <roc> | exactly |
| 21:11 | <wanderview> | and applying styles manually seems like a tooling issue |
| 21:11 | <wanderview> | or framework issue |
| 21:13 | <roc> | having said that, some UI toolkits have adopted CSS as a declarative widget styling mechanism, so it's still helpful for some apps. And it's definitely helpful for more document-like pages. |
| 21:14 | <roc> | another major source of overhead is the content/presentation distinction, which forces browsers to create a parallel tree of CSS boxes, using a sometimes expensive algorithm |
| 21:15 | <roc> | that seems harder to get around... |
| 21:15 | <dglazkov> | the premise of Shadow DOM is that you can have use CSS as it was designed, but break it up into smaller, per-component chunks |
| 21:16 | <roc> | even when we create anonymous boxes, in Gecko we create anonymous elements to back them up, because it's far too much trouble to support naked CSS boxes |
| 21:16 | <dglazkov> | at least in my observation, this leads to much simpler selectors |
| 21:16 | <dglazkov> | applying all CSS inline should be a valid choice for frameworks |
| 21:16 | <dglazkov> | but we as a platform can do better |
| 21:17 | <dglazkov> | in terms of primitive ergonomics |
| 21:18 | <dglazkov> | re: style scoped: https://groups.google.com/a/chromium.org/d/topic/blink-dev/JB8nFQXhAuQ/discussion |
| 21:20 | <wycats> | "but we as a platform can do better" big confirm |
| 21:26 | <dglazkov> | having Shadow DOM is style boundary also a pretty useful thing (without shadow-piercing combinators) |
| 21:26 | <dglazkov> | you could actually start computing style in parallel, for example |
| 21:28 | <dglazkov> | and of course, the shadow root being a natural style invalidation root is a good thing |
| 21:33 | <TabAtkins> | roc: We're nearly done with our parser rewrite, and then Variables is getting put right back in. |
| 21:37 | <wycats> | dglazkov: +1 |
| 21:37 | <wycats> | TabAtkins: +1 |
| 21:38 | <wycats> | TabAtkins: I think you really want the ability to give a component a stylesheet that gets its variables from custom properties |
| 21:38 | <wycats> | component.stylesheets.push(stylesheet) |
| 21:38 | <TabAtkins> | Yeah, variables inherit. |
| 21:38 | <wycats> | hm |
| 21:38 | <wycats> | say more |
| 21:38 | <wycats> | so the component itself would have some variables declared in the top-level sheet |
| 21:38 | <TabAtkins> | Custom properties inherit by default. So you can set them from outside the component, and use them inside the component. |
| 21:38 | <wycats> | sorry some custom properties |
| 21:38 | <wycats> | iiiiinteresting |
| 21:39 | <wycats> | so stylesheets.push, if implemented, would "just work" |
| 21:39 | <TabAtkins> | Yeah. |
| 21:39 | <wycats> | nice |
| 21:39 | <wycats> | please do implement |
| 22:05 | <dglazkov> | wycats: I want that too. I started a discussion a while back, but sadly I got distracted: https://lists.w3.org/Archives/Public/www-style/2012Oct/0491.html |
| 22:13 | <dglazkov> | And when I say "I", I mean "Tab". |
| 22:13 | <dglazkov> | :P |
| 22:15 | <jgraham> | Apropos nothing in particular, I was talking to someone that works on gaia today and it seems like they didn't think web components was going to provide the level of encapsulation they wanted for building FirefoxOS apps (aka web apps) |
| 22:17 | <dglazkov> | jgraham: would love to know more details there |
| 22:18 | <dglazkov> | it's a very generic statement :) |
| 22:20 | <jgraham> | dglazkov: Yeah, I don't want to give some false statement about what they wanted |
| 22:20 | <jgraham> | So I guess I should try to get them to give feedback directly |
| 22:20 | <dglazkov> | jgraham: anyone I could talk to? |
| 22:20 | <dglazkov> | I don't bite |
| 22:20 | <dglazkov> | anymore |
| 22:21 | <dglazkov> | :) |
| 22:23 | <jgraham> | It wasn't exactly clear to me what they did want, but they were talking about a solution that had multiple documents which is apparently good if you want to destroy one piece and reclaim all the memory, and allows building a clear message-based API |
| 22:24 | <jgraham> | I'm not really sure if/how this solved problems relating to styling |
| 22:25 | <jgraham> | (to be fair their solution didn't sound very sane to me, so as you can tell I am not a great proxy here) |
| 22:27 | <dglazkov> | :-\ |
| 22:28 | <dglazkov> | maybe we could meet with them and try to have a brainstorm or something? Sounds like they're in a crazypants land |
| 22:29 | <smaug____> | well, separate docs especially from different domains give you rather good encapsulation ;) |
| 22:34 | <jgraham> | dglazkov: I'll see if there's someone who can provide actual useful feedback |
| 22:42 | <TabAtkins> | dglazkov: You're not at your desk, so... do we still have a flag for resetting inheritance on the shadow tree? Or do you need to use a dummy element with 'all'? |
| 22:53 | <Domenic> | I was very disappointed in `all: unset`. It was too much. I think I want `all-but-display: unset`. I dunno, maybe it's workable in combination with a list of default-block elements. |
| 22:54 | <Domenic> | I was very disappointed in `all: unset`. It was too much. I think I want `all-but-display: unset`. I dunno, maybe it's workable in combination with a list of default-block elements. |
| 23:09 | <dglazkov> | TabAtkins: |
| 23:10 | <dglazkov> | TabAtkins: no flag. Must use 'all'. |
| 23:12 | <dglazkov> | jgraham: thanks! |
| 23:15 | <gsnedders> | jgraham: thoughts on html5lib question above? |
| 23:17 | <jgraham> | gsnedders: I don't think it's worth changing. |
| 23:18 | <gsnedders> | jgraham: (the stuff I'm doing as part of the expected failures and skipped tests etc. is rewriting all this anyway) |
| 23:19 | <smaug____> | jgraham: how do I check where and why certain wpt test was added |
| 23:20 | <jgraham> | gsnedders: I don't really care either way. I would err on the side of changing less, but if you think it's a big win that's fine |
| 23:20 | <jgraham> | smaug____: Look in the git history? |
| 23:21 | <smaug____> | like where? :) |
| 23:21 | smaug____ | wonders what window-named-properties-001.html is about and why it would be valid |
| 23:24 | <jgraham> | smaug____: git clone https://github.com/w3c/web-platform-tests.git |
| 23:25 | <jgraham> | Author: Yuta Kitamura <yutak⊙gc> |
| 23:25 | <jgraham> | Date: Fri Jun 21 13:49:27 2013 +0900 |
| 23:26 | <jgraham> | So it's getting on for two web-component years old. Which are like 14 internet years, or 98 real years |
| 23:29 | <smaug____> | thanks |
| 23:30 | <gsnedders> | I'm running Firefox on Arch Linux, using the provided package. Firefox is reporting the Flash plugin as being out of date (11.2.202.440), yet looking at the so it's claiming to load it's 11.2.202.442. Any idea what's going on here? https://www.adobe.com/software/flash/about/ claims I have 11.2.202.442 too. (#firefox came up with the useful suggestion of removing Flash…) |
| 23:35 | <jgraham> | gsnedders: Step 1) Convince BBC to stop using Flash for iPlayer. Step 2) There are no remaining use cases for Flash so remove it with fire. Step 3) There is no step 3) |