17:34:02 <RRSAgent> RRSAgent has joined #webapps
17:34:02 <RRSAgent> logging to http://www.w3.org/2013/06/21-webapps-irc
17:34:24 <ArtB> RRSAgent, make log public
17:34:24 <ArtB> RRSagent, this meeting spans midnight
17:34:24 <ArtB> RRSAgent, make minutes
17:34:24 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html ArtB
17:34:36 <jkomoros> ScribeNick: jkomoros
17:35:13 <ArtB> ScribeNick: jkomoros
17:35:14 <jkomoros>   rrsagent, this meeting spans midnight
17:35:16 <ArtB> Scribe: Alex
17:35:57 <jkomoros> Present+ Edward_OConnor
17:36:05 <jkomoros> Present+ Ryosuke_Niwa
17:36:15 <ArtB> Meeting: WebApps' Web Components f2f Meeting
17:36:15 <ArtB> Agenda: http://www.w3.org/wiki/Webapps/WebComponentsJune2013Meeting
17:36:15 <ArtB> Chair: Dimitri
17:36:21 <jkomoros> Present+ Bear_Travis
17:36:23 <ArtB> RRSAgent, make minutes
17:36:23 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html ArtB
17:36:29 <jkomoros> Present+ Divya_Manian
17:36:34 <jkomoros> Present+ Alex_Komoroske
17:36:39 <jkomoros> Present+ David_Baron
17:36:43 <jkomoros> Present+ Priyank_Singhal
17:36:56 <jkomoros> Present+ Steve_Orvell
17:36:56 <dfreedm> dfreedm has joined #webapps
17:37:05 <jkomoros> Present+ Daniel_Freedman
17:37:10 <jkomoros> Present+ Dimitri_Glazkov
17:37:20 <jkomoros> Present+ Elliott_Sprehn
17:37:27 <singhalpriyank> singhalpriyank has joined #webapps
17:37:27 <jkomoros> Present+ Scott_Miles
17:37:53 <sorvell> sorvell has joined #webapps
17:38:10 <jeffh> jeffh has joined #webapps
17:38:32 <betravis> betravis has joined #webapps
17:39:10 <jkomoros> Chair: Dimitri_Glazkov
17:39:29 <jkomoros> Meeting: Styling Issues in Shadow DOM and CSS
17:40:53 <rniwa> rniwa has joined #webapps
17:42:34 <jkomoros> Topic: Quick Overview of Shadow DOM concepts
17:42:36 <divya> i think we need cofffee
17:43:02 <jkomoros> DG: Hoping that the main focus of this meeting will be primarily arounds CSS + Shadow DOM
17:43:18 <jkomoros> ... we had one original idea, but developers trying to use it gave feedback that it wasn't exactly the right "knobs"
17:43:35 <jkomoros> ... there are people here who are "Browser Vendors", and there are people who are the "web developers"
17:43:56 <rniwa> but needs tea instead
17:44:04 <jkomoros> ... a bunch of folks in the latter group here are from Polymer, Daniel Buchner (who should join at some point) represents x-tags
17:44:05 <Ms2ger> s/but needs tea instead//
17:44:16 <divya> Ms2ger: oMG YOU ARE STALKING EVERYTHING
17:44:21 <jkomoros> ... and then spec folks, fantasai and tabatkins
17:44:22 <Ms2ger> s/Ms2ger: oMG YOU ARE STALKING EVERYTHING//
17:44:27 <jkomoros> ... who aren't here yet.
17:44:30 <rniwa> Ms2ger: i think i'm allergic to coffee though :/
17:44:47 <jkomoros> dbaron: Blake Kaplan and William Chen (?) have been working on Shadow DOM at Mozilla
17:44:51 <jkomoros> ... and I've been talking with them
17:45:42 <tross> tross has joined #webapps
17:47:13 <Ms2ger> s|Ms2ger: i think i'm allergic to coffee though :/||
17:47:30 <Ms2ger> RRSAgent, make minutes
17:47:30 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
17:51:04 <jkomoros> [by the way, we all took a coffee break]
17:51:36 <rniwa> rniwa has joined #webapps
17:52:23 <jkomoros> [break over]
17:52:49 <jkomoros> DG: The general idea of Shadow DOM is that you have an ability to create trees, like before, but connected for rendering purposes, render in place of nodes in document
17:52:54 <rniwa> wasn't there explainer somewhere?
17:53:16 <jkomoros> ... this existed in many different systems before. It allows composability (one tree vs multiple)
17:53:17 <rniwa> is https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html still up to date?
17:53:25 <jkomoros> ... if I can replace the rendering of a node, what happens to its children?
17:53:28 <slightlyoff> rniwa: or, also: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
17:53:50 <jkomoros> ... the general overview gets trickier and trickier, but we have converged on a solution in today's Shadow DOM spec
17:53:58 <jkomoros> [dglazkov draws a diagram on the board]
17:54:06 <rniwa> Also see: https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/
17:54:30 <jkomoros> ... every node that has children, you can associate (off to the right) with a shadowRoot: a DocumentFragment with extra stuff in it
17:54:41 <slightlyoff> rniwa: this loads for me: https://dvcs.w3.org/hg/webcomponents/raw-file/57f8cfc4a7dc/explainer/index.html
17:54:53 <jkomoros> ... extra stuff is effectively a subclass of DocumentFragment. Things like getElementByID, querySelector. Stuff that has migrated into Document mainly anyway
17:55:00 <jkomoros> dbaron: So those just query what's in the Shadow DOM?
17:55:04 <rniwa> slightlyoff: oh oops, yeah. i guess it doesn't have an ordinary index.html > / rewrite :/
17:55:21 <jkomoros> DG: think of the line connecting ShadowRoot is not a normal connection--it's a separate tree
17:55:38 <jkomoros> ... insertion points can be any elements inside the tree. They're called <content>
17:55:44 <jkomoros> ... we use a rhombus for insertion points
17:55:48 <jkomoros> ... <content> name comes from XBL2
17:55:52 <jkomoros> ... you can have more than 1 content
17:56:10 <jkomoros> ... content can have a select attribute, which takes a narrow subset of CSS selctors
17:56:16 <jkomoros> ... that match against children of the parent node.
17:56:23 <jkomoros> ... currently limited to ID, tagname, attributes, and class
17:56:31 <jkomoros> ... no combinators.
17:57:01 <jkomoros> ... that's the conceptual model. But actually a node can have MULTIPLE shadow roots
17:57:24 <jkomoros> ... the method on the ndoe is "createShadowRoot"
17:57:26 <jkomoros> ... there's an ordering.
17:57:37 <jkomoros> ... Sometimes the element already has a shadowtree (like InputElement or TextArea)
17:57:55 <jkomoros> ... they're basically the same as how the native implementation might be done
17:58:14 <jkomoros> ... it's actually a stack of trees. new ones go on top of old ones; the newest one is the visible one. The ones underneath don't render
17:58:25 <jkomoros> ... there's a concept of older and younger shadow tree
17:58:33 <jkomoros> ... youngest one is the one that gets rendered
17:58:50 <jkomoros> ... soemtimes you want to use parts of the older shadow tree
17:59:02 <jkomoros> ... which is why there's an insertion point called <shadow>
17:59:17 <jkomoros> ... when you put it in a shadow root, it will show whatever what is the older shadow root
17:59:28 <jkomoros> ... it allows the youngest guy to channel the older guy
17:59:41 <jkomoros> ... explicit children can only go to one insertion point.
18:00:16 <jkomoros> ... there's an idea conceived by Jan on the polymer-dev list, the shadow acting as a function (?)
18:00:26 <jkomoros> ... but as of now, there is an order, only selected once
18:00:42 <jkomoros> ... this allows developers to take existing elements, and adorn them with existing stuff from older shadow trees
18:01:05 <jkomoros> ... if there's nothing in the older shadow tree, it works as the last content element--whatever hasn'
18:01:06 <darobin> darobin has joined #webapps
18:01:12 <jkomoros> ... been distributed
18:01:43 <Ms2ger> s/hasn'/hasn't/
18:01:53 <jkomoros> ... whole point of Shadow DOM spec  is distributed. That's the majority of the spec
18:02:10 <jkomoros> ... how are they distributed, what's the effect
18:02:13 <jkomoros> ... things like focus, events, and rendering/sytling
18:02:20 <jkomoros> ... the latter is what I want to talk abou ttoday
18:02:36 <jkomoros> ... the others we have figured out mostly
18:03:17 <jkomoros> dbaron: I was involved in the XBL RCC thing in 2004 (?) so these concepts are not all new to me
18:03:25 <jkomoros> DG: now we get into style
18:03:29 <jkomoros> ... this is where things get interesting
18:03:31 <dbaron> (also XBL1 :-)
18:03:51 <jkomoros> ... if the shadow root is a document fragment, what does that mean from styling perspective?
18:04:02 <jkomoros> ... if I'm distributing a text node into a content element, what is its style?
18:05:40 <jkomoros> rniwa: What does hte current spec say about style?
18:05:50 <Ms2ger> s/hte/the/
18:05:56 <Ms2ger> RRSAgent, make minutes
18:05:56 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
18:06:15 <jkomoros> [I missed about 30 seconds :-( ]
18:06:29 <jkomoros> dbaron: I think it's worth separting selector matching and inheritance
18:06:51 <jkomoros> [esprehn draws a diagram on the board]
18:08:22 <jkomoros> es: When you attach the shadow root, content doesn't render. But in this shadow, the content is "teleported" as though it was there when rendering
18:08:37 <jkomoros> ... so you get styles from where you came from, and styles where you're going
18:08:49 <jkomoros> ... there's a way to reset styles at shadow boundary
18:09:22 <divya> http://s3.amazonaws.com/Gyazo/1371838156.png
18:09:44 <jkomoros> ... when the tree gets flattened out, conceptually it gets flattened out
18:10:16 <jkomoros> Present+ Tab_Atkins
18:11:06 <jkomoros> [es draws the "composed" result on the board for clarity]
18:11:45 <jkomoros> ... we use "composed" tree to mean, the thing with all of the things teleported
18:11:49 <jkomoros> ... don't use "flattened" tree
18:12:06 <jkomoros> dg: Although at some point we might, depending on if there's mutiple trees
18:12:45 <jkomoros> rniwa: If you have a style in the distributed content, that follows hierarchy in original content
18:12:53 <jkomoros> ... and merge in with shadow styles
18:12:59 <jkomoros> ... I'm not sure that even in an complex widget that makes sense
18:13:02 <jkomoros> ... things get really wonky
18:13:16 <jkomoros> sorvell: It's just inherited styles that work this way
18:13:44 <jkomoros> es: One special case si that if you have a style inside of the shadow root, it's automatically scoped to the shadow root
18:13:52 <jkomoros> s/style/style element/
18:14:16 <jkomoros> dbaron: So the selectors in the scoped style only match things in the shadow tree, NOT stuff that gets "teleported" there
18:14:28 <jkomoros> sorvell: This is one part of the spec as a developer that makes total sense
18:14:41 <jkomoros> ... allows you to worry just about this shadow root. it works really well in practice
18:14:51 <jkomoros> sjmiles: Occasionally you have to pierce through that barrier, that's when it gets harder
18:14:57 <divya> http://s3.amazonaws.com/Gyazo/1371838492.png
18:15:00 <jkomoros> ... as a practical matter WE haven't run into that problem
18:15:07 <jkomoros> ... (confused styles)
18:15:13 <fantasai> fantasai has joined #webapps
18:15:28 <jkomoros> dbaron: By pierce through, do you mean that someimes you want the explicit children of the node to inherit from what before as opposed to from shadow dom?
18:16:34 <jkomoros> ... is there a way to say that, in that case, the span shoul dinherit font size but not color
18:16:39 <jkomoros> sjmiles: no, it's all or nothing
18:16:53 <jkomoros> ... (basically)
18:17:01 <jkomoros> ... we haven't run into that need in practice y et
18:17:18 <jkomoros> ... that's based on empirical data with n points, where n is a relatively small number in the grand scheme of things
18:17:30 <jkomoros> ... it's possible at some point in the future someone will need it, but we don't now
18:17:44 <jkomoros> dg: let's enumerate the cool styling hooks that we have today, then figure out which ones are missing
18:17:48 <jkomoros> ... 1) Style scoped.
18:18:02 <jkomoros> ... it's acgtually a close cousin of shadowRoot. It's very similar scoping behavior
18:18:11 <jkomoros> ... but it's a scoping NODE, and style scoped is a scoping ELEMENT
18:18:27 <jkomoros> ... but they have similar abilities, except none of the styles from the document (outside the SR) don't apply down.
18:18:32 <jkomoros> ... style scoped in isolation, essentially
18:19:00 <jkomoros> dbaron: So nothing from the author style sheets don't match SR. But still UA styles
18:19:13 <jkomoros> DG: we have applyAuthorSTyles
18:19:27 <jkomoros> ... that allows the component to explicitly allow outside styles out to come inside
18:19:34 <jkomoros> ... user styles are treated like Author styles
18:20:06 <jkomoros> eo: It's problematic that user styles by default get blocked
18:20:19 <jkomoros> dg: Actually, we don't know what we do here, we need to check
18:20:28 <jkomoros> tabatkins: It's reasonabl eto say, yeah, User styles apply by default
18:20:35 <jkomoros> dbaron: How selector matching works is intersting
18:21:06 <jkomoros> dg: If you say applyAuthorStyles, there's still a weird relationship, where you even though a child of shadowRoot might LOOK like it's child of the host
18:21:15 <jkomoros> ... it's actually not. The selector matching can either be fully in the host, or in the SR
18:21:20 <jkomoros> [I think I got that right?]
18:21:36 <jkomoros> ... so in this example, div > div will not match
18:21:48 <jkomoros> ... but if you just do `div` and have applyAuthorStyles it will match both divs
18:21:58 <jkomoros> sjmiles: If I put div class=foo, and foo is defined in document, it won't see that
18:22:15 <jkomoros> ... as a user I go, applyAuthorStyles will make it work, but it won't
18:22:30 <jkomoros> dg: No, that will work
18:23:05 <jkomoros> es; BAsically, the selector must COMPLETELY Match outside, or completely inside. There's no boundary crossing
18:23:14 <jkomoros> eo: What about a boundary crossing combinator?
18:23:18 <dbaron> db: yeah
18:23:23 <jkomoros> dg: That's what we want to talk about today: :-)
18:23:33 <jkomoros> ... There's another flag on SR that says resetStyleInheritance
18:23:38 <jkomoros> ... it's very powerful
18:23:56 <jkomoros> ... everything inside of the SR, when you flip to true, it will look like it's initial styling
18:24:13 <jkomoros> dbaron: Kind of like you had a parent in between all ::initial (?)
18:24:23 <dbaron> s/all ::initial (?)/all:initial/
18:24:23 <jkomoros> dg: similar thing exists on insertion points
18:24:41 <jkomoros> ... so that you can have the styles in SR not go into the composed children
18:25:11 <jkomoros> ... that's all the styling machinery (minus any boundary-piercing things)
18:25:51 <jkomoros> ... but this isn't enough. how do you make the subtrees intreact with doc?
18:26:09 <jkomoros> ... similarly, sorvell wants to be able to style inside the shadow tree, style the composed children as well
18:26:17 <jkomoros> ... like say in a tab strip, styling the active children
18:26:47 <jkomoros> ... you want to be able to let SOME stuff in from SR in from document, and also in
18:26:51 <jkomoros> ... similar for content
18:27:06 <jkomoros> dbaron: The XBL solution to that is that you have a separate binding for active tab that is different, point to that instead
18:27:28 <jkomoros> dg: We didn't want the content of the host to not know what's happening to it (?)
18:27:40 <jkomoros> ... we had two solutions, both of which have strengths and weaknesses
18:27:59 <jkomoros> ... 1) let CSS Variables bleed through the SR boundary. So you could specify a CSS variable in doc, and catch it inside the SR
18:28:41 <jkomoros> tabatkins: in Style WG, we decided that variable resetting isn't covered in "all". YOu'd need to explicitly say "vars" as well (syntax I probably got wrong)
18:28:52 <jkomoros> dbaron: i don't like describing inheritance blocking as all property
18:29:10 <jkomoros> fantasai: You probably do want the ability to jump inheritance over the shadows
18:29:44 <jkomoros> dbaron: I'm nervous about cutting off inheritance from stuff outside SR to stuff inside. I'm less nervous about inheriting from the shadow into the children
18:30:02 <jkomoros> tabatkins; that turns out to be extremely popular for writing components in the real world
18:30:15 <jkomoros> ... like components in jquery have to go through and manually reset everything
18:30:27 <jkomoros> ... they want consistent, predictable starting point--even if they allow poking in after that
18:31:01 <jkomoros> fantasai: But imagine we're using this to rearrange list items into new structure. The expectation of the author is that setting font on the root of the doc, it sets it everywhere. But if you do cut off inheritance, then those list items will have UA default
18:31:21 <jkomoros> tabatkins: That's why it's a flag. Component authors can decide if it works
18:31:29 <jkomoros> es: Actually, default is to allowing
18:31:41 <jkomoros> sjmiles: So if you turn it off, the component author did it on purpose
18:32:06 <jkomoros> dbaron: So in thec ases where you have a binding wiht lots of content inside, like say a tab widget. You probably want the inheritance through to your big piece of content. Bu there's some little content you don't want it
18:32:47 <darobin> darobin has joined #webapps
18:32:51 <jkomoros> dg: Think about disqus use case. They mostly want it to match the blog they're embedded in. But if you're building an app, you might want a certain style that's very aprticular no matter where it is
18:33:06 <jkomoros> ... like the G+ share widget, as an example, that wants to have complete control over exactly what's inside it
18:33:14 <jkomoros> sjmiles: db makes a good point
18:33:36 <jkomoros> tabatkins: wihtin the shadow, if you want to block it only in some places, the 'all' property exists
18:33:45 <jkomoros> sjmiles: Or make a component for just the parts where you want to reset it
18:33:57 <jkomoros> sorvell: We don't use resetting much in practice, it's such a blunt tool
18:34:07 <jkomoros> ... generally we want to control a small number of properties
18:34:35 <jkomoros> rniwa: In disqus use case, you want to be able to read the background color of surrounding, but decide how to interpet that
18:35:02 <jkomoros> tabatkins: Today you can do that. Use 'all' to reset all, then 'inherit' for the other properties you want to allow in. Or the other way around, use 'initial'
18:35:20 <jkomoros> es: LIke in a facebook button as an example, you want to force the font, but don't care about the size of it
18:35:40 <jkomoros> dg: Let's keep going with explaining the tools
18:35:46 <jkomoros> ... those variables are cool but not enough
18:35:53 <jkomoros> ... we see this alot with WebKit's internal input elements
18:36:02 <jkomoros> ... you want access to a sepcific element to style arbitrarily
18:36:04 <jkomoros> ... leads to:
18:36:08 <jkomoros> ... 2) Custom pseudo elements
18:36:15 <Ms2ger> s/thec ases/the cases/
18:36:26 <Ms2ger> s/aprticular/particular/
18:36:32 <jkomoros> ... you define a pseudo attribute on an element
18:36:45 <jkomoros> ... then you can use it with standard ::foo syntax in selectors
18:37:25 <jkomoros> ...so like <outer-element>::x-foo
18:37:32 <jkomoros> dbaron: Like functionality, but want a function
18:37:34 <jkomoros> eo: agreed
18:37:59 <jkomoros> dg: Agreed, at the time when we proposed this dave hyatt didn't want it to be a functional syntax, but we can revisit
18:38:11 <jkomoros> es: ONe of the goals of the project is to explain lower-level magic
18:38:17 <jkomoros> eo: I don't agree with that goal, for what it's worth
18:38:24 <chaals> chaals has joined #webapps
18:38:35 <jkomoros> es: If we swithc to functional syntax, we miss out on explaining the ::foo magic
18:39:09 <jkomoros> rniwa: We could change the syntax for pseudos like that if we want, only blink and webkit do this
18:39:27 <jkomoros> dbaron: If implementations want to implement web platform features that have pseudos, they can have their own versions that don't use the functional syntax
18:39:43 <jkomoros> ... I'm SLIGHTLY sympathetic to wanting to explain the magic. But some of them are things we really don't want to freeze
18:40:05 <jkomoros> ... like if we had done styling of form controls right back in 2000/2002, it wouldn't have been web-compatible to make the form controls used on iOS and ANdroid
18:40:16 <fantasai> s/right/"right"/
18:40:29 <jkomoros> ... because the web would have depended on fixed structures that work on destop, but don't make sense on mobile devices
18:40:46 <jkomoros> dg: There is a larger debate here. I want to table that for now. Keep it in mind today, but avoid engaging today
18:40:54 <jkomoros> eo: We'll only be able to make so much progress without  it
18:41:06 <jkomoros> dg: So even with this second knob, it doesn't complete all of the use cases from developers
18:41:09 <dbaron> (I think he used "put it aside" rather than "table" (which is en-GB/en-US ambiguous).)
18:41:20 <jkomoros> ... now I'm crossing threshold to the boundary-crossing thing
18:41:29 <jkomoros> ... I'll first describe things they way they WERE/ARE
18:42:48 <jkomoros> divya: What do you mean by "functional syntax"?
18:42:56 <jkomoros> dg: things like ::shadow(foo)
18:43:12 <jkomoros> dbaron: the advantage is, there's a rule in selector spec that says rules UA doesn't understand get dropped
18:43:24 <jkomoros> ... pseudo elements/classes are part of that rule. WebKit/Blink don't do that correctly
18:43:36 <jkomoros> ... all other browsers drop the entire rule, but WebKit/Blink retains those
18:43:42 <jkomoros> es: That was willful; we can fix it
18:43:56 <jkomoros> tabatkins: But peopel do use it today already :-(
18:44:04 <jkomoros> dg: In querySelector, incidetnally, we don't violate spec
18:44:20 <jkomoros> ... onto the new things that we're thinking of
18:44:45 <jkomoros> ... in order to select things that are distirbuted into an insertion point, we invested the distirbuted pseudo element function
18:45:27 <jkomoros> ... ::distributed(---------)
18:45:32 <jkomoros> ... where ----- allows combinators
18:45:54 <jkomoros> ... on an insertion poiint, inside of a SR, it matches the element that was distributed into that matches the inner selector in the function
18:46:22 <jkomoros> es: example: content::dsitributed(span) { border: ________ }
18:46:31 <Ms2ger> s/poiint/point/
18:46:40 <Ms2ger> s/dsitributed/distributed/
18:46:47 <jkomoros> ... in the example we diagrammed, that style that earlier didn't match, now matches
18:47:10 <jkomoros> tabatkins: Remember, this is current junky stuff that we don't like
18:47:30 <jkomoros> es: Essentially content has a list of things that have been distributed in, the selector inside the parens says which in that list to select
18:47:35 <jkomoros> sorvell: It's relative
18:47:54 <jkomoros> dg: It's relative to the virtual node that represents the thing that envelopes all distributed elements
18:48:06 <jkomoros> sorvell: use case: i want to style all children, not all descendants
18:48:27 <jkomoros> ... so you can do like content::distributed( > span)
18:48:35 <jkomoros> es: It's like find() on content
18:48:41 <jkomoros> dbaron: I don't know if I like leading cominbators yet
18:49:00 <jkomoros> fantasai: I have reservations, but I think at this point we have to go with it, everyone expects it to work that way
18:49:15 <jkomoros> tabatkins: jquery uses it for years, and now it's documented in selectors level 4. It's a small section
18:49:31 <jkomoros> dbaron: leading combinators only work when there's an implicit node being targeted to
18:50:09 <jkomoros> sjmiles: This is very necessary in our experience
18:50:26 <jkomoros> divya: Can I have a class on the content element and use that in the selector?
18:50:28 <jkomoros> dg: yes
18:50:36 <jkomoros> es: Although content element itself is NOT stylable
18:50:47 <jkomoros> ... which I don't like. I wish that I could style the content to, say, display:none it
18:50:54 <jkomoros> ... currently it has no effect
18:50:56 <jkomoros> ... it's bizarre
18:50:58 <jkomoros> dg: I agree
18:51:09 <stearns> +1 to styling content nodes
18:51:10 <jkomoros> ... I would like to explain content as a display:contents
18:51:28 <jkomoros> es: In the current model, it's easy to distribute two things, but if you want to hide it, you need ANOTHER wrapper
18:51:45 <jkomoros> ... styles targeted at <content> don't inherit down; it's unstylable, no rendernode
18:52:30 <jkomoros> fantasai: If it's an intermediary, it makes for example uls and lis nested not work
18:52:43 <jkomoros> dg: I hope we can solve it by having <content> have display:contents on it
18:52:57 <jkomoros> fantasai: but that doesn't address the ul/li use case
18:53:11 <fantasai> also mentioned :nth-child
18:53:23 <fantasai> ul/li shouldn't be a problem
18:53:23 <jkomoros> dg: let's talk about @host
18:53:29 <fantasai> otherwise
18:53:30 <jkomoros> ... we want to get rid of thinks
18:53:38 <jkomoros> s/thinks/this
18:54:03 <jkomoros> ... when you put a SR inside a tree, I want to be able to apply borders on the component, for example
18:54:28 <jkomoros> ... works like @host { [selector] { border: 1px solid red }}
18:54:39 <jkomoros> ... the inner selector matches only host
18:54:49 <jkomoros> dbaron: and what would antyhing other than *
18:55:22 <jkomoros> eo: You can imagine a case where you want to embed a widget in two different places, and you only want one (regarding why you'd want something other than *)
18:55:36 <jkomoros> tabatkins: And because of is attribute, you could have one component with different tag-names
18:55:58 <jkomoros> dbaron: So @host lets the SR influence the containing box
18:56:03 <jkomoros> ... I think that in XBL1 we replace the outer box, but I might be misremembering
18:56:17 <jkomoros> dg: This is the entire family of styling stuff. Now we want to get rid of many of these
18:57:27 <chaals1> chaals1 has joined #webapps
18:59:11 <betravis1> betravis1 has joined #webapps
19:00:23 <fantasai> side discussion of pseudo-element syntax, vs . combinators vs. @rule
19:00:43 <fantasai> ::distributed() matches pattern of ::cue() and ::region(), seems we're alinging on that
19:00:43 <heathjs> heathjs has joined #webapps
19:04:17 <dbaron> dbaron has joined #webapps
19:09:04 <fantasai> ScribeNick: fantasai
19:09:09 <fantasai> ... @host did not solve the body class=light, and have components be able to see that
19:09:12 <fantasai> sjmiles: ANd we never used this @host { * {}}
19:09:15 <fantasai> fantasai: You probably want ::shadow, ::light, and ::context (to reach out)
19:09:17 <fantasai> dbaron: or a combinator to jump out
19:09:20 <fantasai> fantasai: Issue with a combinator is that it breaks the rule where combinators limit the matched set as you go
19:09:23 <fantasai> ... so if you did bar <magic cobminator> foo, suddenly you're selecting a different set of foos
19:09:26 <fantasai> dbaron: What I was thinking of was a combinator that would let you get to the scoped root from the selecto rthat's selecting inside it
19:09:29 <fantasai> ... which is adding restrictions, right?
19:09:31 <fantasai> ... in the dark theme use case
19:09:34 <fantasai> tabatkins: yeah, that works with combinator
19:09:36 <fantasai> ... eventually we rejected that idea
19:09:39 <fantasai> [tab opens a Google Doc to show this idea off. He will share a link here]
19:09:41 <fantasai> [we will share the doc later]
19:09:44 <fantasai> docs.google.com/document/d/19fpRugyOO8kZfVVfdN1vkorwv8rmKztfNOEVLzIU2pU/edit?usp=sharing
19:09:45 <jkomoros> jkomoros has joined #webapps
19:09:47 <fantasai> ... does that work?
19:09:49 <fantasai> ... no :-(
19:09:52 <fantasai> tabatkins: host element and shadow have equal claim
19:09:54 <fantasai> ... we need to pretend the hos telement is in the root of the shadow tree
19:09:57 <fantasai> ... so i fyou want to select on it, all you do is [writes in doc]
19:09:59 <fantasai> ... this example will target the host element outside
19:10:02 <fantasai> http://tinyurl.com/mueleah
19:10:04 <fantasai> ^ that link works
19:10:05 <fantasai> s/selecors/selectors/
19:10:08 <fantasai> tabatkins: you want to be able to select based on the content further up in the document. like the theme use case, or modernizer up higher
19:10:11 <fantasai> ... but you don't want to allow arbitrary selecors above
19:10:28 <jkomoros> can you see this?
19:10:33 <dbaron> ScribeNick: jkomoros
19:10:34 <singhalpriyank> yes
19:10:58 <jkomoros> tabatkins: If you have the outer document followed by a shadow element, and inside of that another component
19:11:08 <jkomoros> ... the outer document you would see includes the shadow tree of the outer component.
19:11:25 <jkomoros> ... that breaks encapsulation, allows developers to depend on details of components outside
19:11:34 <jkomoros> ... we still need a communication channel to outside
19:11:48 <jkomoros> ... we think we have a simple thing that satisfies use csaes
19:12:06 <jkomoros> ... here's an example. The context pseudo class is placed on the root element (hsot element)
19:12:18 <jkomoros> ... it matches if something in the compound selector matches in the fully composed ancestor list (?)
19:12:24 <jkomoros> ... including stuff in other boundaries
19:12:34 <jkomoros> ... because maybe you're applying a theme inside of one of the parent components above
19:12:47 <jkomoros> ... it allows some information to be piped through, but not enough to allow a fragile dependency (we hope)
19:13:10 <jkomoros> ... the list of elements checked starts with host element itself, goes up to the root, through any of the composed shadow trees
19:13:15 <jkomoros> ... that's the only way to select up outside
19:13:24 <jkomoros> ... going the other way, we still use ::distributed
19:13:25 <dfreedm> dfreedm has joined #webapps
19:13:27 <jkomoros> ... works the same way
19:13:32 <scheib> scheib has joined #webapps
19:14:02 <jkomoros> ... we think this solves all the use cases we know of
19:14:13 <jkomoros> ... and it's convenient and easy ,not the contorted tree hopping of @host and everything else
19:14:15 <jkomoros> dbaron: What is removed?
19:14:15 <shepazu> shepazu has joined #webapps
19:14:40 <jkomoros> tabatkins: What is removed is the @host (in favor of moving host element into shadow tree for styling purposes, and using context pseudo class to select up)
19:14:43 <dgrogan> dgrogan has joined #webapps
19:15:08 <jkomoros> rniwa: So if you have multiple composed layers, it selects each composited layer (?)
19:15:39 <jkomoros> tabatkins: no, the fully flattened tree up above
19:15:39 <jkomoros> ... you do see the shadow dom of things up the tree... but not very much
19:15:51 <jkomoros> ... so at any point you can inject information in
19:16:01 <jkomoros> rniwa: So a shadow DOM A, inside sahdow dom B
19:16:22 <jsbell> jsbell has joined #webapps
19:16:25 <jkomoros> tabatkins: we haven't changed the way normal selectors work. In a shadow style sheet, still only match within that shadow tree
19:16:46 <jkomoros> ... only thing that I think we might want to change, as a result of the recent discussion aroudn region pseudo-element (as opposed to rule)
19:17:05 <jkomoros> ... the problem is this distributed pseudo class isn't compatible with any nesting mechanisms we might add in future
19:17:40 <jkomoros> ... like, if you had foo bar baz {} as foo { @nest bar baz { ... }} , the distributed pseudo class wouldn't let you do the nested selectors
19:17:51 <jkomoros> ... same problem applies to regions, because regions often have complex selectors inside of the regions
19:18:16 <jkomoros> ... a possible aternate syntax is to have content selected and inside have a @distributed rule that takes ...
19:18:28 <jkomoros> ... content { @distributed { :scope > foo {}}}
19:18:34 <jkomoros> ... behaves similarly, but more future-compatible
19:18:49 <jkomoros> ... it's an @-rule inside of a declaration block
19:18:58 <jkomoros> ... we agreed to use it in error handling rules. This would be the first other use of it
19:19:04 <jkomoros> es: I like the ::distributed
19:19:18 <jkomoros> sjmiles: Yeah, that one is easier to type
19:19:28 <jkomoros> fantasai: what about ::distributed <space> <other stuff>?
19:19:39 <jkomoros> tabatkins: problem about jumping sub-trees, not narrowing matching
19:19:51 <jkomoros> ... if that's not a problem, then maybe that's fine
19:20:11 <jkomoros> es: That space one requires deeper architectural change to selector matching
19:20:26 <jkomoros> sorvell: I don't think the notion of limiting across selectors is something web developers know or care about
19:20:38 <jkomoros> dbaron: I don't think it violates it, although ::distributed is the wrong name in this formulation
19:20:43 <jkomoros> fantasai: light?
19:20:58 <jkomoros> sjmiles: well, one person's light is another person's shade
19:21:26 <tross> tross has joined #webapps
19:21:27 <jkomoros> es: As an implementor I don;t like it
19:21:37 <jkomoros> dg: We have the same basic thing with pseudo elements already
19:21:54 <jkomoros> ... we take this linked list and grab and swap it around at the end
19:21:58 <fantasai> fantasai: It's just a syntactic difference; implementation can store it in whatever structures it wants
19:22:00 <jkomoros> es: yeah, but this would come at the end
19:22:05 <jkomoros> es; Why is this not an @ rule?
19:22:13 <jkomoros> ... like @teleport
19:22:27 <dbaron> I'd rather have content::back-to-light-dom > .foo { ... }
19:22:38 <dfreedm> dfreedm has joined #webapps
19:23:00 <jkomoros> tabatkins: You don't want you to accidentally select hidden things in shadows above you
19:23:33 <jkomoros> dbaron: I think that we want selectors that continue to the right of pseudo elements. And the impleemntatin model there is treat them like you treat pseudoelements today, where you match the thing to the left first, and then you
19:23:40 <jkomoros> ... say , oh, pseudo element, do this other stuff
19:23:47 <jkomoros> ... I think it makes sense without parens
19:23:59 <singhalpriyank> s/impleemntatin/implementation
19:23:59 <jkomoros> es: But selector matchign starts from right side
19:24:16 <jkomoros> dbaron: not really, not with pseudo-elements. You have to start from just to the left of hte pseduo-element
19:24:22 <stearns> the key is that we're combining two selectors. You can still use right-to-left evaluation on each piece
19:24:32 <jkomoros> ... now we're going to allow more stuff to the right of ::, but still same model
19:24:48 <jkomoros> es: why is the other thing not good as a functional syntax but this is?
19:24:55 <jkomoros> dbaron: Because it's a singular thing (?)
19:25:08 <jkomoros> es: The current distributed thing matches cue
19:25:24 <jkomoros> dbaron: Tab doesnt want's functional syntax because nested syntax will come along in the ftuure
19:25:33 <jkomoros> es: I'm not comfortable with rewriting whole selector checker
19:25:38 <jkomoros> dg: You just do it when parsing rules
19:25:55 <jkomoros> tabatkins: Find first pseudo element, run part before it, then ... [didn't get]
19:25:58 <sorvell> sorvell has joined #webapps
19:26:06 <jkomoros> es: But it's not "at end", it's a nesting relationship. It's more complicated
19:26:23 <jkomoros> tabatkins: exactly like a b is not all b's just b's inside of a's
19:26:36 <jkomoros> dbaron: I agree it's hard. I think we want implementation experience on concept before we commit to using it
19:26:50 <jkomoros> ... but it's the same concept we've come up with in multiple places already (like overflow fragments, here, regions)
19:26:57 <jkomoros> fantasai: cue?
19:27:15 <jkomoros> es: cue currently works like distributed does
19:27:23 <jkomoros> ... distributed is consistent with that
19:27:35 <jkomoros> ... the inner selector in there is not even HTML, it's a totally different world
19:27:45 <jkomoros> tabatkins: But different constraints: the document exposed is completely flat
19:27:54 <jkomoros> ... whereas this will expose more complex things inside the parens
19:28:01 <dbaron> It needs to be called the see-you-eee element (the "cue" element) and not the queue element (the "q" element)
19:28:17 <jkomoros> dfreedm: I've hit this before. Nesting would be great
19:28:32 <jkomoros> es: What people are arguing for is a "reuse this selector" ability in CSS, like a #define for selectors
19:28:50 <jkomoros> dbaron: But with that, you'd end up having something with an unmatched parens in your #define,
19:28:58 <jkomoros> tabatkins: yeah, that would be painful
19:29:44 <jkomoros> sjmiles: Looking at the multiple {} solution, if I write that rule, I might be tempted to ask, can I put stuff to the right that is different than what's to the left? (?)
19:29:50 <jkomoros> ... as a developer, it's just getting in my way. Confusing.
19:30:03 <jkomoros> es: In this syntax, how do I match stuff that is a sibling of the stuff that's distributed
19:30:27 <jkomoros> ... example: content::distributed(> .foo) + span {}
19:30:29 <jkomoros> ... what does that do?
19:30:38 <jkomoros> tabatkins: That doesn't do anything in current syntax
19:31:05 <jkomoros> ... given the assumptions of functional syntax, we're doing that because "only one pseudo element, and at end rule". So this is nonsense, because it comes after pseudo-element
19:31:19 <jkomoros> ... but content::distributed > .foo {} is also nonsensical
19:31:29 <jkomoros> dbaron: So you want a pseud-class instead of a pseudo-element?
19:31:42 <jkomoros> es: I want to style the heading element that immediately follows the first heading element
19:32:16 <jkomoros> tabatkins; The general use case of dropping down to jump back up (?) is a generic discussion not limited to this discussion
19:32:27 <jkomoros> es: I'll reserve judgement, but I don't know what happens if you have two distributed
19:32:39 <jkomoros> tabatkins: You can never ahve a double distributed, because content nodes are gone
19:32:42 <jkomoros> dg: yes you can
19:32:42 <fantasai> content:matches(!::distributed > .foo) + span
19:32:51 <jkomoros> ... imagine that you're inside of a tree that's inside of a shadow tree
19:33:04 <jkomoros> tabatkins: But as far as you can tell, you're not in a distributed tree (?)
19:33:35 <jkomoros> ... content::distirbuted > .foo::region p content {} will never match anything
19:33:42 <jkomoros> es: ... no?
19:33:51 <jkomoros> tabatkins: remembe,r the :context selects on flattened tree
19:34:03 <jkomoros> ... below you, any contents you contain you can't access content
19:34:19 <cabanier> cabanier has joined #webapps
19:34:21 <jkomoros> es: That's not how it's currently specced. It's currentlys pecced that elements are distirbuted, but not that <content> is gone
19:34:40 <jkomoros> tabatkins: But it doesn' matter for the purpose of this example
19:34:55 <jkomoros> dg: What he's proposing works the same way as one with parens, just no parens
19:35:19 <jkomoros> es: So in <an example> you could have interleaved with multiple implied parens
19:35:57 <jkomoros> dg: Positive impression from CSS people around dropping parens?
19:36:02 <jkomoros> ... what about people who implement?
19:36:14 <sgalineau> sgalineau has joined #webapps
19:36:20 <jkomoros> dbaron: It doesn't seem easy, I think we should get implementation experience before we commit, but I think it's probably the right thing
19:36:43 <jkomoros> tabatkins; So we leave spec as it is right now, we add notes with paren-less version, that says implement and give feedback, if it does work then we use it
19:37:15 <jkomoros> ... someone has to solve these similar problems (e.g. in regions) first that leads the solution
19:37:19 <stearns> I'm happy to change to this
19:37:37 <jkomoros> es: So you change region, and hixie changes cue?
19:37:49 <jkomoros> dbaron: cue might be a special case? it's selecting into a different document
19:38:19 <jkomoros> es: I want to hear from apple
19:38:35 <jkomoros> rniwa: We don't like ANY changes. ideally we wouldn't implement anything, but we'll have to implement SOMETHING
19:38:43 <jkomoros> dg: I'm interested in how hayato-san feels about this
19:38:48 <jkomoros> ... and see how much he screams
19:39:04 <Zakim> Zakim has left #webapps
19:39:26 <jkomoros> eo: my rule of thumb is to let dbaron do his experiment and see what happens
19:39:44 <jkomoros> ACTION: tabatkins to update the spec to the paren-less version of the :context, with a note that we will use that syntax if implementors don't scream after experimenting with implementation
19:39:44 <trackbot> Error finding 'tabatkins'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
19:40:28 <jkomoros> es: It's defiintely implementable, it's a question if the implementation cost justifies the developer confusion benefit
19:40:46 <jkomoros> dbaron: Remember, either of these solutions is hard
19:40:57 <jkomoros> dg: so instead of a list, it's a tree
19:41:22 <jkomoros> ... so what will happen is that at parsing you'll have to be aware that when you see this pseudo-element you change what you've seen already into a tree and parse selector again
19:41:51 <jkomoros> es: One of these was described in a grammar. But the current proposal can't be done in a grammar; it's context sensitive
19:42:06 <jkomoros> ... so it makes it harder to implement. The parser has to be made more complex
19:42:59 <fantasai> s/:context/:distributed/
19:43:06 <jkomoros> (in the action above)
19:43:20 <jkomoros> dg: context is confusing, because it looks like content
19:43:36 <jkomoros> es: what about "projection"
19:43:39 <jkomoros> rniwa: THat's too complicated
19:43:44 <jkomoros> dbaron: Let's get rid of context entirely
19:43:50 <jkomoros> es: what about ":path"
19:43:51 <slightlyoff> slightlyoff has joined #webapps
19:44:03 <jkomoros> dg: ":composed"
19:44:26 <jkomoros> dfreedm: I prefer path
19:44:34 <jkomoros> es: "has" looks closer to "matches"
19:44:44 <jkomoros> sjmiles: Front end developers want everything to be as short as possible
19:45:14 <jkomoros> rniwa: What about ":host" since we got rid of @host?
19:45:17 <jkomoros> sjmiles: not bad
19:45:23 <jkomoros> dbaron: agreed
19:45:33 <jkomoros> es: But this could be arbitrary levels above
19:46:10 <jkomoros> rniwa: I like ancestor
19:46:16 <jkomoros> eo/sjmiles: I find it confusion
19:46:20 <jkomoros> fantasai: I like host best
19:46:40 <jkomoros> es: What about :inside?
19:46:59 <jkomoros> sjmiles: that's the opposite of how we think about it as devleopers
19:47:08 <jkomoros> rniwa: yeah, I'd expect that to be OUTSIDE
19:47:31 <jkomoros> es: If we do distributed shenanigans, why don't we do same thing here?
19:47:42 <jkomoros> dbaron: This is intentionally limited
19:47:56 <dfreedm> too late
19:48:00 <jkomoros> dbaron: I think we're moving to :host?
19:48:05 <jkomoros> tabatkins: not bad
19:48:21 <jkomoros> es: but x is the host here, and the theme is on body
19:48:39 <jkomoros> es: path makes sense, like a traversal path
19:48:48 <jkomoros> fantasai: What if you allowed host element to be matched in host
19:49:06 <jkomoros> tabatkins: you can: :host(*)
19:49:38 <jkomoros> sjmile: Is there a way to avoid me having to write "x" all the time for my placehodler
19:49:44 <jkomoros> ... now we don't use the name, we just use @host
19:49:52 <jkomoros> tabatkins: no need to worry about it. will only match pseudo element
19:50:15 <jkomoros> es: is there a way to reference your host without explicit tag name?
19:50:24 <jkomoros> tabatkins: you can: :host()
19:50:33 <jkomoros> es: how does that differ from :scope
19:50:44 <jkomoros> tabatkins: no, because things aren't actually scoped
19:50:50 <jkomoros> ... the shadow is not actually a scoped style sheet
19:51:05 <jkomoros> ... it happens to be scoped, but it isn't technically a scoped style
19:51:15 <jkomoros> es: I think we should go with :host()
19:51:21 <jkomoros> tabatkins: We can omit empty parens
19:51:27 <jkomoros> rniwa: I like :host
19:52:15 <jkomoros> proposed resolution: :host(<simple selector on ancestor path>), or :host, which is equivalent to :host(*)
19:52:26 <jkomoros> fantasai: What's the specificity
19:52:37 <jkomoros> tabatkins: I think we can add the specificity inside the host (?)
19:53:07 <dbaron> I think s/simple selector/chain of simple selectors without combinators/
19:53:11 <jkomoros> es: what about like [data-foo]:host(.dark)
19:53:58 <jkomoros> RESOLUTION: :host(<chain of simple selectors without combinators on ancestor path>), or :host, which is equivalent to :host(*)
19:54:40 <jkomoros> sjmiles: This is a different concept than ancestor. It has some similarity to "something that's above me"
19:54:59 <jkomoros> ... it feels a bit weird to put what would be on the left side would be in the parens to the RIGHT
19:55:10 <jkomoros> whoops, sorry strike that resolution
19:55:22 <jkomoros> I misunderstood what "resolution" meant in this context
19:56:43 <jkomoros> thanks for the information! I'll get the hang of this some day :-)
19:57:19 <jkomoros> sjmiles: To be clear, this syntax is fine, but ultimately developers would have wanted somethign similar: .dark goes on left, then some host, then wormhole
19:57:23 <jkomoros> ... but this is fine, given all the constraints.
19:57:43 <dbaron> just wait until I propose :上(.dark)
19:58:03 <jkomoros> tabatkins: earlier we had a ^ combinator which said (jump boundary), but it was weird because you could have only one simple thing on the left
19:58:24 <dbaron> or :下(.dark)?  Not sure which makes more sense.
19:58:47 <jkomoros> ... I think it's easier to internalize the restrictions that things inside the parens play by different rules than the things on the left of that magic combinator
19:59:31 <jkomoros> rniwa: I agree the ^ is weirder than :hsot
19:59:41 <jkomoros> s/:hsot/:host/
20:00:12 <Ms2ger> s/RESOLUTION:/CONCLUSION:/
20:00:14 <tross_> tross_ has joined #webapps
20:00:17 <Ms2ger> RRSAgent, make minutes
20:00:17 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/21-webapps-minutes.html Ms2ger
20:01:26 <jkomoros> [discussion has gotten disorganized; scribe has been unable to keep up for the past 2 minutes]
20:01:40 <jkomoros> fantasai: We should agree that words should either be plural or not plural
20:02:04 <fantasai> fantasai: And CSS already has 'content' in some places
20:03:21 <jkomoros> CONCLUSION: rename ::distributed to ::content
20:03:32 <jkomoros> sjmiles: you don't need to have the content ahead of the ::content
20:03:48 <jkomoros> fantasai: This helps people remember what it means, what concepts it's connected to
20:04:03 <fantasai> (because the tag name is content -- distributed is just out of the blue)
20:04:07 <jkomoros> rniwa: Ideally the developer needs to know the minimum of terrms
20:04:26 <dbaron> so 'content: contents' in http://dev.w3.org/csswg/css-content/#contents0 should be 'content: content' ?
20:04:35 <fantasai> either that or something else, yeah
20:05:09 <jkomoros> [lunch break]
20:30:22 <betravis> betravis has joined #webapps
20:38:51 <marcosc> marcosc has joined #webapps
20:40:25 <jkomoros> [lunch break over]
20:40:32 <jkomoros> dg: Any more CSS - related topics?
20:40:51 <jkomoros> dbaron: I don't know if we agreed if custom pseudos should be functional or not?
20:40:54 <jkomoros> eo: Yes
20:41:15 <jkomoros> es: I think it would be said to sacrifice explanatory effect
20:41:19 <jkomoros> dg: I agree with that
20:41:46 <jkomoros> eo: I think it makes sense; it calls out that pseudos you come across are from a component somewhere, as opposed to from the system
20:42:05 <jkomoros> ... there's a clarity that gets sacrificed by confusing the two
20:42:24 <jkomoros> tabatkins: Even if we use no (), we still need to have a prefix (?)
20:43:01 <jkomoros> ... even the explanatory power of a non-functional syntax is still limited because custom ones would have to be named in a way that wouldn't conflict with new ones
20:43:19 <jkomoros> es: Okay, I won't fight for it
20:43:29 <jkomoros> dg: dbaron mentioned a solution I'm okay with
20:43:32 <TabAtkins> TabAtkins has joined #webapps
20:43:43 <jkomoros> ... have a switch in shadow DOM spec that says that UA can define pseudos if they want
20:44:09 <jkomoros> es: Long ago, the idea that in this future world all the quirks of the bedrock go away, evertyhing is components and who cares
20:44:14 <TabAtkins> TabAtkins has left #webapps
20:44:15 <jkomoros> ... but we're leaving warts all over the place
20:44:32 <jkomoros> sjmiles: There's a tension. Sometimes it's a clarity concept, but sometimes user doesn' tneed to know
20:44:52 <jkomoros> eo: In the future with lots of components, you can clearly tell when you're dealing with a part of a components
20:45:07 <jkomoros> es: Why need a prefix? Why can't you implement ::placeholder
20:45:26 <jkomoros> tabatkins: We want to avoid namespaces that are unchecked, so that we don't have to worry about compat checks for new keywords in the future
20:45:56 <jkomoros> es: Why not expose things that are actually inside of shadow roots, why aren't they just a namespace open to anyone?
20:46:07 <singhalpriyank> singhalpriyank has joined #webapps
20:46:13 <jkomoros> ... placeholder is specced
20:46:26 <jkomoros> ... you'd need to say ::part(placeholder) (?)
20:46:45 <jkomoros> eo: you wouldn't want to expose it as a shadow root; it's an implementation detail
20:46:56 <jkomoros> es: But every browser implements placeholder in the same way
20:47:09 <jkomoros> ... and this argument is, what if someone hypothetical browser wants to do it some other way?
20:47:21 <jkomoros> dbaron: Placeholder in gecko uses native anonymous content
20:47:39 <jkomoros> ... that's different from XBL, which is different from web components
20:48:09 <jkomoros> es: Gecko creates divs inside of an input element, right?
20:48:32 <jkomoros> dbaron: The inside of a select box is more complicated. There are things in there that have boxes but no content nodes for those boxes
20:48:41 <jkomoros> ... which is different from Native Anonymous Content
20:48:55 <jkomoros> ... because NAC is where we construct actual content nodes and construct boxes for those
20:48:59 <jkomoros> ... for a select we just make boxes
20:49:18 <jkomoros> es: I don't understand the harm in claiming that <input> uses component model
20:49:44 <jkomoros> ... like, keep ::placeholder. But why not also allow the new syntax to address the same thing?
20:50:01 <jkomoros> eo: Because the implementors can choose how to implement it!
20:50:13 <jkomoros> dg: The question is not, whether it's implemented with Shadow DOM, but rather how it interacts with rest of content
20:50:26 <jkomoros> ... so you don't have all of these weird behaviors and edge cases. It's all described by semantics of shadow DOM
20:50:37 <jkomoros> dbaron: You assume shadow dom will be web compatible
20:50:55 <jkomoros> dg: We have implemented almost all crazy elements uses Shadow DOM machinery
20:51:09 <jkomoros> ... everything exceltp select, which we have plans to switch over as well
20:51:14 <jkomoros> ... it's been for two years now that we've been using it
20:51:48 <jkomoros> es: If I have input::part(placeholder) and it was a normal input, now I inherit it, I shouldn't have to change the CSS that targets it; I should just have a placeholder pseudo in my new shadow dOM
20:51:57 <jkomoros> [murmurs of aggremeent from sjmiles, dg]
20:52:01 <jkomoros> dg: yeah, big fan
20:52:27 <jkomoros> ... part() comes from an old discussion
20:52:53 <jkomoros> dbaron: There are three sorts: pseudos that are not tree like, some that are leaf like, some are tree-like and contain real emenets
20:53:05 <jkomoros> ... CSS doesn't define any in the third category. But there's been discussion about various ones
20:53:17 <jkomoros> es: ::first-line can't possibly be implemented as an element, for example
20:53:29 <jkomoros> ... it's different from somethign that can be exposed as an API surface to style
20:53:34 <singhalpriyank> s/emenets/elements/
20:53:42 <jkomoros> dfreedman: I don't understand why it has to be different
20:53:50 <jkomoros> eo: part() takes an author-defined dient
20:53:56 <jkomoros> s/dient/ident/
20:54:21 <jkomoros> sjmiles: I think it's a strong point: this is a specific kind of styling we're doing here--it's a node. It's the same for web components and implemented pieces
20:54:33 <jkomoros> ... it seems this makes sense. It makes sense that ::first-line is different
20:54:49 <jkomoros> dg: it's hard to explain ::backdrop in terms of these primitives
20:54:53 <jkomoros> ... so that would stay the same
20:55:04 <jkomoros> es: like there are some things that are clearly defined by what's inside
20:55:07 <jkomoros> ... like scrollbars
20:55:14 <jkomoros> eo: I disagree about scrollbars
20:55:22 <jkomoros> dbaron: We plan to get rid of all internals to scrollbars
20:55:34 <jkomoros> es: What kinds of scrollbars would you not want to build in the div
20:55:56 <jkomoros> rniwa: That's for the scrollbars that have been released to date; in the future they might not
20:56:23 <jkomoros> eo: Currently in WebKit if you use legacy pseudos for scrollbars, you go to legacy scrollbar mode. If you don't, then you get the special new ones
20:56:50 <jkomoros> es: What I'm saying is that if you don't want the API surface, don't expose it. In this case, it's already been exposed
20:57:04 <jkomoros> sjmiles: I think it's reasonable to say, for this thing, the way we implement it we shouldn't reveal it
20:57:20 <jkomoros> eo: I want to make a distinction between UA-implemented things, and things built in WC world. We want that distinction
20:57:33 <jkomoros> es: But why? If the standard says ::placeholder, it cannot be removed entirely
20:57:56 <jkomoros> ... so for new ones, it should use part() so that others can override later. But if it's not exposed, doesn't matter
20:58:08 <jkomoros> dg: it gives a clear message to author of how to reason about it--it's just like Shadow DOM.
20:58:22 <jkomoros> ... the UA is acting as an author in those cases where the guts are exposed like this
20:58:36 <jkomoros> rniwa: We don't want to be adding APIs that limit the ways in which we can tweak UIs
20:59:05 <jkomoros> dg: agreed. I don't think it matters. ::placeholder behaves like it's implemented as Shadow DOM. So it should behave htat way fully
20:59:38 <jkomoros> eo: The entire existing platform prior to the feature means that user-land psueods and UA pseudos are different
20:59:58 <jkomoros> es: today in WebKit, ::-webkit-spin-button IS a div today. That's an API surface
20:59:59 <singhalpriyank> s/htat/that/
21:00:04 <jkomoros> ... right now it has a prefix
21:00:29 <jkomoros> ... but if a spec adds a non-prefixed api surface, it's now a real API surface and it should behave like the other non-magic things
21:00:45 <jkomoros> eo: as an author, I want to be able to send a bug report to the right person
21:01:16 <jkomoros> dbaron: Authors aren't the users. End users are the user. Web platforms are designed for both of those constiunenciies. Sometimes you don't want to give control
21:01:28 <jkomoros> es: But we're talking about, for things that ARE already exposed
21:01:47 <jkomoros> dbaron: Some of the motivation for it, is there's stuff that might be the same now, but we don't want to be stuck with it forever
21:01:56 <jkomoros> eo: we're stuck with legacy scrollbar contrrols forever. :-(
21:02:20 <jkomoros> dbaron: mobile use cases are a great example. I'm glad we didn't commit to select's having a dropdown button
21:02:36 <jkomoros> ... I think you're being conservative about what to expose
21:02:48 <jkomoros> es: You seem to be arguing that ::placeholder was a mistake and we should remove immediately?
21:03:02 <jkomoros> dbaron: I think freezing everything about form controls at this moment is a bad thing.
21:03:10 <jkomoros> dg: I think we're talking about two different things
21:03:52 <jkomoros> sjmiles: UAs should be able to choose what to expose. But, IF you have chosen what to expose, like ::placeholder, then what you expose is Shadow DOM
21:04:08 <jkomoros> dg: ::placeholder already behaves, as specced today, as a custom pseudo-element
21:04:16 <jkomoros> ... as if it was a custom pseudo-element
21:04:35 <jkomoros> rniwa: Spec doesn't say that ::placeholder needs to be text inside a Shadow DOM. Just that color and whatever can be controlled
21:04:42 <lmclister> lmclister has joined #webapps
21:04:47 <jkomoros> ... this allows UAs to match the convention of the platform
21:05:21 <jkomoros> rniwa: placeholder is okay, but in case of like scrollbars, we have to show legacy scroll bars even on platforms that have other scrollbars --it's confusing ot users
21:05:36 <jkomoros> es: I don't care so much about scroll bars; mozilla doesn't want to implement them
21:06:02 <jkomoros> ... I'm saying when it's a standardized API surface, it should be exposed with Shadow DOM
21:06:07 <jkomoros> eo: take input type=password
21:06:14 <jkomoros> ... users before authors, etc
21:06:29 <jkomoros> ... it would be reasonable for an impelemnter to say that user type=password cannot be overriden by components
21:06:36 <jkomoros> es: that's fine, the standard should say that for those cases
21:06:55 <jkomoros> dbaron: I think there's another answer to this requirement
21:07:04 <jkomoros> ... your requirement is about re-impelmenting existing parts of the platform
21:07:19 <jkomoros> ... I'm okay with the component model having a way to match an existing part of the web platform
21:07:30 <jkomoros> ... that's different from saying that you can extend the pseudo-element space arbitrarily
21:08:10 <jkomoros> es: To clarify, I'm arguing we should do ::part(). And that we should fix the platform to fit this
21:08:13 <karl> karl has joined #webapps
21:08:33 <jkomoros> eo: Dbaron is saying that I want to impelement a new component and react to ::placeholder. Because it's an existing platform feature, you should have a way to say, this thing is my ::placeholder
21:08:47 <jkomoros> ... and then if you add a new pseudo, it goes in the box where user-land new pseudos go
21:09:10 <jkomoros> sjmiles: Eliot's proposal does everything yours says, but simpler, from our perspective
21:09:32 <jkomoros> es: We all seem to be talking from different contexts
21:09:38 <jkomoros> sjmiles: I think we're closer than we think we are
21:09:59 <jkomoros> dbaron: eliot wants ::part(placeholder) to react to all the same thigns that ::placeholder does. I think they should be two different name spadces, and Shadow DOM should be able to get to both of them
21:10:21 <jkomoros> sjmiles: But you're telling Bob Web Developer that in case A you use this syntax, but in case B use a different one. But there's no difference
21:10:35 <jkomoros> ... why does it matter what comes from UA and what comes from a component?
21:10:57 <jkomoros> rniwa: That is an API surface. It's a namespace issue
21:11:15 <jkomoros> es: It doesn't matter if you don't reproject
21:11:36 <jkomoros> dbaron: the reason I don't like them being the same, that goes back to the assumption you'd implement all of the platform in Shadow DOM
21:11:48 <jkomoros> sjmiles: I think rniwa has a good point about namespaces
21:11:50 <jkomoros> *namespace
21:12:16 <jkomoros> rniwa: We could have collisions with new formalized pseudos if they share the same namespace
21:13:03 <jkomoros> es: ::part(placeholder) is exactly like a method that gets stomped on by some new web platform feature adding a new method to a type of node
21:13:12 <jkomoros> ... those types of collisions happen all the time.
21:13:42 <jkomoros> es: You're trying to protect yourself from one, particular type of namespace collision. THere are lots of them!
21:14:04 <jkomoros> dbaron: There's a different error-handling rule for pseudos, and WebKit implemented something else, and didn't come back to the standards groups
21:14:16 <jkomoros> ... now you come back and say you want to build a new feature on top of that broken feature
21:14:35 <jkomoros> es: We agreed on that part--we should move to ::part(placeholder)
21:14:50 <jkomoros> ... isn't this like saying, custom elements are bad idea
21:14:57 <jkomoros> eo: yes! I think you should only do it if it's a good idea
21:15:06 <jkomoros> dfreedman: but how do you know in advance if htey'll have a good reason?
21:15:09 <jkomoros> s/idea/reason/
21:15:20 <singhalpriyank> s/htey'll/they'll/
21:15:29 <jkomoros> es: I'm saying, all platform widgets, however they're implemented (jquery, etc) they should have the same API surface
21:15:38 <jkomoros> ... not if you use Shadow DOM surface.
21:15:54 <jkomoros> dfreedman: part(oplaceholder) just describes the same thing as ::placeholder
21:16:08 <jkomoros> dg: eo is saying htat part defines user-defined pseudos
21:16:18 <jkomoros> dbaron: I think I'm okay with either formulation (?)
21:16:29 <jkomoros> rniwa: think about for example, translation attribute
21:16:38 <jkomoros> ... we shipped and broke a lot of libraries in india
21:16:56 <jkomoros> eo: We have compat constraints we need to take into account
21:17:04 <jkomoros> rniwa: We want to avoid breaking existing websites
21:17:25 <jkomoros> es: If we go there, and say part is magical only userland, and every pseudo in user space should start with data- so you don't conflict
21:17:35 <jkomoros> ... so you're saying that every method in say polymer has to be polymer_foo()
21:17:52 <jkomoros> sjmiles: We tried somethign at the beginning, where we presented a different public face. Developer users HATED it
21:17:59 <jkomoros> ... developers want more power AND backwards compatibility. It's hard.
21:18:37 <jkomoros> rniwa: MediaWiki added a special style attribute to work around WebKit bug
21:18:58 <jkomoros> ... we fixed it, but now we can't remove it because mediawiki content is deployed with the old stuff
21:19:19 <jkomoros> eo: Quickly: this is the same argument from last F2F: the idea if we should allow custom element names over the wire
21:19:32 <jkomoros> ... is=foo nicely delineates which is user land
21:19:41 <tross> tross has joined #webapps
21:19:42 <jkomoros> dg: it's solved with the - requirement
21:19:55 <jkomoros> rniwa: I'm less concerned if authors can only extend HTMLEleement
21:20:19 <jkomoros> es: Either developers are responsible for avoiding namespace collisions everywhere, or nowhere
21:20:32 <singhalpriyank> s/HTMLEleement/HTMLElement/
21:20:33 <jkomoros> sjmiles: Seems like everyone agrees the ::part() is a good idea in many cases
21:20:50 <jkomoros> CONCLUSION: ::part() is a good solution for user-land pseudo elements
21:21:10 <jkomoros> ... although the group doesn't necessarily agree about existing pseudo elements at this point
21:21:37 <jkomoros> dg: ::Part and ::pseudo is fine (?)
21:21:43 <dbaron> (by either formulation -- one formulation is that ::pseudo and ::part(foo) are just two different namespaces, shadow DOM can't extend the first namespace, but it can create things that match either -- the other formulation is that ::part(foo) is an extensible namespace and future Web features that could be represented as such a part (whether or not they are implemented in terms of shadow DOM) plus ::placeholder should have such parts done as ::part(foo), an
21:21:44 <dbaron> d that ::part(placeholder) should be an alias for ::placeholder for consistency
21:21:52 <dbaron> )
21:22:01 <divya> divya has joined #webapps
21:22:16 <jkomoros> CONCLUSION: the attribute to register these custom pseudos is "part" (not pseudo as it currently is in spec)
21:24:41 <jkomoros> The CSS portion of this discussion is over. We'll stop taking notes h ere
21:33:05 <marcosc> marcosc has joined #webapps
21:58:11 <jeffh> jeffh has joined #webapps
22:09:55 <marcosc> marcosc has joined #webapps
22:23:33 <divya> divya has joined #webapps
22:27:22 <marcosc_> marcosc_ has joined #webapps
23:06:45 <marcosc> marcosc has joined #webapps
23:21:37 <marcosc> marcosc has joined #webapps
23:27:11 <betravis> betravis has joined #webapps
00:15:53 <marcosc> marcosc has joined #webapps
01:10:09 <marcosc> marcosc has joined #webapps
01:32:02 <sgalineau> sgalineau has joined #webapps
01:35:04 <MikeSmith> .win 15
02:04:25 <marcosc> marcosc has joined #webapps
02:24:43 <cabanier> cabanier has joined #webapps
02:58:41 <marcosc> marcosc has joined #webapps
03:02:19 <cabanier1> cabanier1 has joined #webapps
03:03:46 <cabanier1> cabanier1 has joined #webapps
03:25:20 <sgalineau> sgalineau has joined #webapps
03:52:57 <marcosc> marcosc has joined #webapps
04:00:22 <skddc> skddc has joined #webapps
04:08:47 <yoichio_> yoichio_ has joined #webapps
04:09:54 <heath> heath has joined #webapps
04:10:09 <skddc_> skddc_ has joined #webapps
04:47:13 <marcosc> marcosc has joined #webapps
05:41:30 <marcosc> marcosc has joined #webapps
06:30:38 <lmclister> lmclister has joined #webapps
06:32:59 <Ms2ger> Ms2ger has joined #webapps
06:35:46 <marcosc> marcosc has joined #webapps
07:27:15 <Lachy> Lachy has joined #webapps
07:30:02 <marcosc> marcosc has joined #webapps
08:12:47 <marcosc> marcosc has joined #webapps
09:09:33 <marcosc> marcosc has joined #webapps
09:10:27 <chaals> chaals has joined #webapps
09:18:01 <marcosc> marcosc has joined #webapps
09:37:02 <karl> karl has joined #webapps
10:15:06 <marcosc> marcosc has joined #webapps
10:24:15 <marcosc> marcosc has joined #webapps
10:43:02 <skddc> skddc has joined #webapps
10:54:44 <marcosc> marcosc has joined #webapps
11:31:16 <marcosc> marcosc has joined #webapps
11:31:26 <marcosc> marcosc has joined #webapps
11:42:01 <marcosc_> marcosc_ has joined #webapps
12:28:22 <marcosc> marcosc has joined #webapps
12:38:20 <karl> karl has joined #webapps
13:22:38 <marcosc> marcosc has joined #webapps
13:57:26 <chaals> chaals has joined #webapps
14:16:54 <marcosc> marcosc has joined #webapps
14:25:33 <Lachy> Lachy has joined #webapps
14:34:19 <marcosc> marcosc has joined #webapps
15:57:54 <Lachy> Lachy has joined #webapps
15:59:15 <sgalineau> sgalineau has joined #webapps
16:00:55 <marcosc> marcosc has joined #webapps
16:12:13 <marcosc> marcosc has joined #webapps
16:26:30 <sgalineau> sgalineau has joined #webapps
16:33:29 <shepazu> shepazu has joined #webapps
16:41:58 <marcosc> marcosc has joined #webapps
17:11:28 <marcosc> marcosc has joined #webapps
17:11:34 <marcosc> marcosc has joined #webapps
17:24:11 <Lachy> Lachy has joined #webapps
17:47:31 <marcosc> marcosc has joined #webapps
18:44:38 <marcosc> marcosc has joined #webapps
19:39:05 <marcosc> marcosc has joined #webapps
20:26:26 <sgalineau> sgalineau has joined #webapps
20:33:21 <marcosc> marcosc has joined #webapps
20:37:28 <smaug> smaug has joined #webapps
20:48:58 <smaug> smaug has joined #webapps
21:16:08 <smaug> smaug has joined #webapps
21:27:38 <marcosc> marcosc has joined #webapps
22:03:02 <karl> karl has joined #webapps
22:03:37 <lmclister> lmclister has joined #webapps
22:16:12 <sgalineau> sgalineau has joined #webapps
22:21:54 <marcosc> marcosc has joined #webapps
23:16:10 <marcosc> marcosc has joined #webapps
00:10:26 <marcosc> marcosc has joined #webapps
02:08:08 <marcosc> marcosc has joined #webapps
03:02:28 <yoichio> yoichio has joined #webapps
03:02:31 <marcosc> marcosc has joined #webapps
03:04:16 <cabanier> cabanier has joined #webapps
03:10:52 <cabanier1> cabanier1 has joined #webapps
03:10:55 <lmclister> lmclister has joined #webapps
03:56:47 <marcosc> marcosc has joined #webapps
04:51:02 <marcosc> marcosc has joined #webapps
05:45:18 <marcosc> marcosc has joined #webapps
06:39:34 <marcosc> marcosc has joined #webapps
07:02:07 <Ms2ger> Ms2ger has joined #webapps
07:33:50 <marcosc> marcosc has joined #webapps
08:26:52 <chaals> chaals has joined #webapps
08:28:04 <marcosc> marcosc has joined #webapps
08:29:56 <smaug> smaug has joined #webapps
09:06:15 <chaals> chaals has joined #webapps
09:22:17 <marcosc> marcosc has joined #webapps
09:35:22 <chaals> chaals has joined #webapps
10:06:53 <jungkees> jungkees has joined #webapps
10:16:30 <marcosc> marcosc has joined #webapps
11:10:46 <marcosc> marcosc has joined #webapps
11:39:19 <marcosc> marcosc has joined #webapps
12:05:00 <marcosc> marcosc has joined #webapps
12:05:34 <marcosc_> marcosc_ has joined #webapps
12:50:23 <marcosc> marcosc has joined #webapps
13:26:11 <marcosc> marcosc has joined #webapps
13:26:20 <marcosc> marcosc has joined #webapps
14:23:16 <marcosc> marcosc has joined #webapps
14:24:33 <smaug> smaug has joined #webapps
14:25:16 <marcosc_> marcosc_ has joined #webapps
15:22:20 <marcosc> marcosc has joined #webapps
16:16:34 <marcosc> marcosc has joined #webapps
16:24:44 <smaug> smaug has joined #webapps
17:10:50 <marcosc> marcosc has joined #webapps
18:05:07 <marcosc> marcosc has joined #webapps
18:19:12 <lmclister> lmclister has joined #webapps
18:33:58 <marcosc> marcosc has joined #webapps
19:26:21 <smaug> smaug has joined #webapps
20:14:42 <lmclister> lmclister has joined #webapps
20:17:24 <smaug> smaug has joined #webapps
20:19:01 <chaals> chaals has joined #webapps
20:51:52 <chaals1> chaals1 has joined #webapps
20:54:31 <cabanier> cabanier has joined #webapps
21:07:20 <lmclister> lmclister has joined #webapps
21:27:21 <shepazu> shepazu has joined #webapps
23:03:53 <smaug> smaug has joined #webapps
03:13:47 <lmclister> lmclister has joined #webapps
04:45:53 <lmclister> lmclister has joined #webapps
06:29:57 <Ms2ger> Ms2ger has joined #webapps
07:26:33 <dom> dom has joined #webapps
07:38:12 <chaals> chaals has joined #webapps
08:41:33 <Hixie> Hixie has joined #webapps
08:54:09 <tobie> tobie has joined #webapps
08:58:20 <smaug> smaug has joined #webapps
09:48:39 <darobin> darobin has joined #webapps
10:24:04 <chaals> chaals has joined #webapps
10:31:02 <abarsto> abarsto has joined #webapps
10:41:10 <chaals> chaals has joined #webapps
11:32:22 <chaals> chaals has joined #webapps
12:11:33 <smaug> smaug has joined #webapps
12:34:13 <karl> karl has joined #webapps
12:51:50 <chaals> chaals has joined #webapps
13:16:52 <marcosc> marcosc has joined #webapps
13:24:30 <chaals> chaals has joined #webapps
13:29:41 <smaug> smaug has joined #webapps
13:34:33 <davidb> davidb has joined #webapps
13:54:48 <lmclister> lmclister has joined #webapps
13:58:59 <davidb_> davidb_ has joined #webapps
14:00:44 <marcosc_> marcosc_ has joined #webapps
14:05:50 <chaals> chaals has joined #webapps
14:08:44 <skddc> skddc has joined #webapps
14:36:47 <jungkees> jungkees has joined #webapps
14:52:58 <davidb_> davidb_ has joined #webapps
14:59:50 <marcosc> marcosc has joined #webapps
15:00:12 <skddc> skddc has joined #webapps
15:24:17 <marcosc> marcosc has joined #webapps
15:32:15 <davidb> davidb has joined #webapps
15:50:50 <cabanier> cabanier has joined #webapps
15:54:43 <divya> divya has joined #webapps
16:00:25 <cabanier1> cabanier1 has joined #webapps
16:06:46 <divya1> divya1 has joined #webapps
16:24:10 <skddc> skddc has joined #webapps
16:54:39 <skddc> skddc has joined #webapps
16:59:41 <jsbell> jsbell has joined #webapps
17:05:08 <divya> divya has joined #webapps
17:10:59 <chaals> chaals has joined #webapps
17:19:34 <divya> divya has joined #webapps
17:24:53 <smaug> smaug has joined #webapps
17:45:40 <abarsto> abarsto has joined #webapps
17:59:44 <davidb_> davidb_ has joined #webapps
18:06:40 <divya> divya has joined #webapps
18:59:25 <tobie> tobie has joined #webapps
19:24:23 <dglazkov> dglazkov has joined #webapps
19:30:34 <divya> divya has joined #webapps
19:35:37 <Lachy> Lachy has joined #webapps
20:08:20 <divya> divya has joined #webapps
20:12:35 <skddc_> skddc_ has joined #webapps
20:22:08 <tantek> tantek has joined #webapps
20:55:49 <lmclister> lmclister has joined #webapps
21:01:49 <smaug> smaug has joined #webapps
21:06:18 <tobie> tobie has joined #webapps
21:07:58 <divya> divya has joined #webapps
21:34:19 <tobie> tobie has joined #webapps
21:45:28 <skddc_> skddc_ has joined #webapps
21:49:52 <sgalineau> sgalineau has joined #webapps
21:50:33 <sgalineau> sgalineau has joined #webapps
21:51:14 <sgalineau> sgalineau has joined #webapps
21:52:43 <sgalineau> sgalineau has joined #webapps
21:54:32 <sgalineau> sgalineau has joined #webapps
21:57:49 <divya> divya has joined #webapps