16:07:14 <RRSAgent> RRSAgent has joined #tagmem
16:07:14 <RRSAgent> logging to http://www.w3.org/2014/04/01-tagmem-irc
16:07:16 <trackbot> RRSAgent, make logs public
16:07:16 <Zakim> Zakim has joined #tagmem
16:07:18 <trackbot> Zakim, this will be TAG
16:07:18 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:07:19 <trackbot> Meeting: Technical Architecture Group Teleconference
16:07:19 <trackbot> Date: 01 April 2014
16:07:36 <JeniT> Meeting: Technical Architecture Group Face to Face
16:07:59 <JeniT> Chair: Dan Appelquist & Peter Linss
16:08:14 <JeniT> Scribe: Jeni Tennison
16:08:17 <JeniT> ScribeNick: JeniT
16:09:39 <JeniT> Present: Domenic, Yehuda, Dan, Yves, Tim, Jeni, Peter, Sergey, Anne, Dave
16:12:19 <twirl> twirl has joined #tagmem
16:14:28 <JeniT> Topic: Agenda Planning
16:17:47 <twirl> twirl has joined #tagmem
16:18:44 <JeniT> Agenda: https://www.w3.org/wiki/TAG/Planning/2014-04-F2F
16:27:25 <dka> dka has joined #tagmem
16:27:29 <JeniT> http://www.w3.org/community/ortc/
16:28:16 <annevk> annevk has joined #tagmem
16:28:21 <annevk> http://htmlpreview.github.io/?https://raw.github.com/openpeer/ortc/20131103/ortc.html
16:33:45 <JeniT> Present- Dave
16:33:50 <JeniT> Present+ Alex
16:33:55 <timbl> cf https://raw.github.com/openpeer/ortc/20131103/ortc.html#informative-references
16:34:10 <timbl> vs http://htmlpreview.github.io/?https://raw.github.com/openpeer/ortc/20131103/ortc.html
16:34:23 <timbl> the internal links don’t work
16:35:53 <timbl> <rant>Why won’t people design version control system websites to fit around the web site itself when the VCS is being used to make a web site.
16:36:01 <timbl> </rant>
16:37:46 <timbl> They can go as deep they want, but of the myriadd views of the data, just keep the raw url for the finished product.
16:38:36 <timbl> The finsihed web siteif the onlythink which needs to have clean URIs.  Everything else can have parameters and decoration all over the URI.
16:42:52 <timbl> timbl has joined #tagmem
16:44:32 <JeniT> Topic: Extensible Web Summit Planning
16:45:45 <JeniT> dka: we'll start the day with some curated lightning talks (5 mins)
16:46:10 <JeniT> ... to get people's creative juices flowing
16:46:43 <JeniT> ... then we'll have a barcamp-style grid
16:47:24 <JeniT> ... and there will be sessions around those topics
16:48:41 <JeniT> ... and then anyone else can suggest topics
16:49:12 <JeniT> ... and we'll invite people who have suggested topics to speak a few words about them to give extra context
16:53:41 <JeniT> Present- Alex
16:54:32 <timbl> (http://htmlpreview.github.io/?https://raw.github.com/openpeer/ortc/20131103/ortc.html should be avaialble at https://github.com/openpeer/ortc/20131103/ortc.html)
17:00:37 <JeniT> wycats__: can we have collaborative scribing?
17:00:56 <JeniT> dka: yes, but someone needs to set it up
17:01:48 <annevk> dka: http://oksoclap.com/
17:02:10 <JeniT> [discussion of using wiki to record URLs of collaborative notes]
17:03:16 <JeniT> dka: we have 88 signups so far
17:04:54 <JeniT> Topic: TC39 Update
17:05:46 <JeniT> wycats__: we need Dave for that
17:05:55 <JeniT> Topic: Capability URLs Draft
17:06:25 <JeniT> http://www.w3.org/TR/capability-urls/
17:06:36 <Domenic> JeniT: not too much to say; need more input to move on to the next stage
17:06:50 <plinss> plinss has changed the topic to: https://www.w3.org/wiki/TAG/Planning/2014-04-F2F
17:06:58 <plinss> plinss has changed the topic to: https://www.w3.org/wiki/TAG/Planning/2014-04-F2F
17:07:03 <plinss> plinss has changed the topic to: https://www.w3.org/wiki/TAG/Planning/2014-04-F2F
17:07:04 <plinss> plinss has changed the topic to: https://www.w3.org/wiki/TAG/Planning/2014-04-F2F
17:07:13 <Domenic> dka: we didn't follow up with a PR campaign for getting comments from relevant parties.
17:07:52 <Domenic> dka: when I presented to developers at a meetup, I got a lot of positive encouragement (although not actionable feedback)
17:08:29 <Domenic> wycats__: we should reach out to the GitHubs of the world, and ask if they agree with our guidance. If they are doing something against the guidance, do they agree it's bad, or do they think guidance should be changed?
17:09:09 <Domenic> JeniT: other examples include Dropbox (but that's password reset, which is generic)...
17:09:36 <Domenic> wycats__: Google sharing is generally based on capability URLs. Note they have ACLs on top of it... they have a capability URL mode...
17:09:54 <Domenic> JeniT: Google Calendar is more purely capability URLs
17:10:17 <Domenic> wycats__: Google clearly has thoughts on this based on the way they present things in UI
17:10:25 <Domenic> JeniT: other examples are Doodle and Flickr
17:12:04 <JeniT> annevk: HTTPS leaks Referer when requesting off-origin HTTPS
17:12:20 <JeniT> wycats__: that seems completely broken
17:12:30 <JeniT> annevk: it's broken for capability URLs
17:12:54 <JeniT> Domenic: we can try to get a change in browsers, or advise people to use a redirecter
17:13:12 <JeniT> annevk: CSP policy covers this
17:13:25 <JeniT> ... also rel=noreferer
17:13:43 <JeniT> wycats: should add redirector to the document
17:14:12 <JeniT> ... rel=noreferer only works when you have the ability to add that rel
17:14:22 <annevk> To be clear, that's a new proposed CSP policy
17:14:26 <annevk> I'm not sure it's implemented yet
17:14:46 <JeniT> timbl: URLs have been extended to pieces
17:15:00 <JeniT> wycats: there's lots of places where metadata is desired, and it's being put into URLs
17:15:01 <Domenic> wycats: browsers use URLs in many ways where it's hard to tag on metadata like noreferrer. <a> is only one place.
17:15:38 <JeniT> timbl: could we add magic strings in URLs to indicate it's a capability URL?
17:15:50 <JeniT> wycats: we'll run out of ways to do that
17:16:10 <JeniT> ... because there are only so many odd characters to include
17:16:35 <JeniT> timbl: zip URLs are different because you're embedding URLs/fragments in URLs
17:16:58 <JeniT> ... but with capability URLs you could add ;capability=true to the URL
17:17:18 <JeniT> wycats: URLs weren't designed for extensibility like this
17:17:40 <JeniT> ... !s for example are supposed to be reserved, but actually aren't treated like this
17:17:59 <JeniT> timbl: this is like .well-known
17:18:34 <JeniT> ... who is using ?capability=true in their existing URLs?
17:18:51 <JeniT> wycats: params get put into databases
17:19:08 <JeniT> annevk: there are two issues: how do I protect referers
17:19:31 <JeniT> ... and the other one is if you have a URL, there are whole bunch of additional things you want to say about it
17:19:52 <JeniT> wycats: the integrity URLs have the same thing
17:20:12 <JeniT> annevk: it protects against rogue CDNs
17:20:41 <JeniT> wycats: you provide a SHA along with the URL
17:21:02 <JeniT> ... in the jQuery case you don't want to fetch it again, if the SHA matches
17:21:20 <Domenic> http://w3c.github.io/webappsec/specs/subresourceintegrity/
17:21:27 <JeniT> ... there is additional metadata
17:22:01 <JeniT> ... which we try to add via attributes in tags, which we can't do all the time
17:22:13 <JeniT> dka: the draft addresses existing scenario, not fixing browser behaviour
17:22:32 <JeniT> annevk: wycats is raising a larger problem, which is that whenever there's a URL you want to have a bunch of additional parameters
17:22:41 <JeniT> ... eg srcset on img
17:22:58 <JeniT> ... where you need the extra properties for these new URLs
17:23:09 <JeniT> Domenic: is there a quick fix for capability URLs?
17:23:20 <JeniT> wycats: the only quick fix is the redirect
17:23:37 <JeniT> ... noreferer doesn't work because you can't put it everywhere
17:24:13 <JeniT> annevk: for all third-party resources that you don't trust
17:25:32 <JeniT> JeniT: so you'd refer to same-origin server, which provided 302 redirects to relevant resources
17:26:01 <JeniT> twirl: for images you'd have to proxy
17:26:15 <JeniT> Domenic: maybe github have found this pain point already, or maybe they don't care
17:26:50 <JeniT> [redirector strips out Referer]
17:27:07 <JeniT> dka: also need to account for CSP in the document
17:27:59 <annevk> http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#referrer
17:28:04 <JeniT> ... that should be another recommendation, to always use this CSP, even though browsers don't support it yet
17:28:35 <JeniT> JeniT: what should the recommendation be?
17:28:52 <JeniT> annevk: I think you either want to do 'origin' or 'origin-when-cross-origin'
17:28:58 <JeniT> ... or 'none'
17:29:39 <JeniT> ... Google wants to use 'origin-when-cross-origin' for example
17:29:46 <JeniT> Domenic: there's no 'none-when-cross-origin'
17:30:02 <JeniT> annevk: we could introduce that if there's a use case
17:30:25 <JeniT> ... 'none-when-downgrade' is the current default, which doesn't work
17:30:38 <JeniT> Domenic: if you're using vanity capability URLs with the subdomain as the capability
17:30:44 <JeniT> annevk: but then you don't want to use origin
17:30:50 <JeniT> Domenic: right, then you want to use 'none'
17:31:03 <JeniT> annevk: if the capability isn't in the path or query, you need to use 'none'
17:32:09 <JeniT> timbl: imagine if instead URLs were designed with domain names in the other order, and with /s as the separator
17:32:28 <JeniT> ... would we be able to have cross-origin security extrapolated down the path?
17:32:41 <JeniT> annevk: you'd do it from the IP address
17:33:31 <JeniT> timbl: from the PoV of security, you might have separate areas with different security
17:33:42 <JeniT> wycats: you can do that with ServiceWorker
17:34:13 <JeniT> annevk: but you can still access APIs, it's all origin-bound
17:34:19 <JeniT> wycats: you could have APIs that were per-ServiceWorker
17:34:38 <JeniT> timbl: I wonder whether we should move towards having the URL space more strictly hierarchical for security purposes
17:34:53 <JeniT> Domenic: that's almost less necessary over time, now that it's easy to get a domain name
17:35:38 <JeniT> timbl: it would be good if you have a storage account to hive off different parts of it
17:35:44 <JeniT> ... that's how filesystems work
17:36:47 <Domenic> wycats: yeah, it's related to how "members.aol.com/username" is a massive security anti-pattern
17:37:29 <JeniT> dka: the action plan
17:38:46 <JeniT> ... make the specific changes that we've discussed re CSP & redirects
17:39:39 <JeniT> JeniT: ask for issues on the capability-urls repo
17:39:52 <JeniT> dka: we need to do a blog post about the draft
17:39:58 <JeniT> ... I'm happy to do that
17:40:47 <JeniT> JeniT: so wycats is pinging someone at GitHub
17:40:51 <JeniT> ... Yves someone at Flickr
17:41:02 <JeniT> Yves: we should ask slightlyoff to ping someone at Google
17:41:45 <JeniT> JeniT: wait a month then do another draft?
17:41:47 <JeniT> dka: yes
17:43:05 <JeniT> timbl: shouldn't you have a 403 rather than a 404 or 410 when the capability URL expires?
17:43:36 <JeniT> ... eg when booking a flight and the session expires
17:43:54 <JeniT> Yves: if the capability URL expires, do you want to expose the fact that it existed or not?
17:44:03 <JeniT> wycats: mostly you don't
17:44:17 <JeniT> ... GitHub will just give you a 404, it pretends it doesn't exist
17:45:22 <JeniT> ... the point is that you don't want to expose the capability URL because that enables brute-forcing
17:46:03 <JeniT> BREAK
18:15:56 <Domenic> Topic: 209
18:16:16 <Domenic> wycats: you need to catch Domenic up on the fact that there is a controversy surrounding 303...
18:17:18 <Domenic> JeniT: the problem being addressed is URLs/resources which do not have representations anyone wants to send
18:17:39 <Domenic> The URL/resource has a relationship with another URL/resource that *does* have a representation
18:18:08 <Domenic> JeniT: examples... (see slides)
18:19:29 <Domenic> JeniT: at the moment we handle this via a 303
18:21:01 <Domenic> JeniT: but 303 causes two round-trips, has problems pre-HTTP 1.1bis
18:21:39 <Domenic> wycats: does this impact licensing problem?
18:21:50 <Domenic> JeniT: not really; this level of discussion is not about that
18:22:06 <Domenic> JeniT: final problem is that it hurts linking because the redirect URL is the one people copy and paste
18:23:58 <Domenic> JeniT: the proposal is "209 Contents of Related"; a draft exists based on discussions within Linked Data Platform Working Group (who ran into the linking issue)
18:24:10 <Yves> about bookmarkability, see also http://www.w3.org/TR/cuap (that might need an update)
18:25:00 <Domenic> wycats: to clarify, 209's body would be the related content, whereas 303's body would describe the redirect
18:25:22 <Domenic> annevk: why does this require a new status code? E.g. deliver the partial body and add Link rel="complete"
18:25:43 <Domenic> JeniT: issues with 209. Which resource do headers apply to?
18:25:49 <Domenic> wycats: that *is* the licensing problem actually
18:26:52 <Domenic> JeniT: how do apps that only recognize 200 react, etc.
18:27:11 <Domenic> JeniT: various alternatives discussed on www-tag
18:28:37 <Domenic> Various discussion of use cases...
18:30:13 <Domenic> wycats: the semantics you are trying to get across is that "what you are looking at is not the current URL"
18:32:07 <Domenic> Discussion of per-media-type ways of solving this problem, e.g. RDF solves this problem
18:32:40 <Domenic> Yves: this seems like a UI problem
18:33:00 <Domenic> slightlyoff: wycats, you are saying we should hoist this metadata into a header so the UI can address it?
18:33:04 <Domenic> wycats: yes, essentially
18:33:45 <Domenic> slightlyoff: this has specific impacts on the manifest format we + Mozilla are working on. Addressing the application vs. addressing content the application hosts.
18:34:56 <Domenic> slightlyoff: e.g. the difference between bookmaking and article and saving/bookmaking "the blog" containing that article (i.e. as a "homescreen app")
18:35:02 <annevk> dka: can I invite other Mozillians to attend sessions?
18:35:10 <Domenic> slightlyoff: I'm hoping to use some combination of manifests and service workers
18:35:12 <dka> q?
18:35:13 <dka> q+
18:35:48 <Domenic> slightlyoff: service workers allow you specify app scope... (didn't quite follow this)
18:36:36 <Yves> on the bookmarking issue http://www.w3.org/TR/cuap#cp-bm-neg (now updated with permalinks and other use cases)
18:36:50 <Domenic> wycats/slightlyoff: this is basically a browser limitation; there is only one URL bar that needs to represent two things
18:37:18 <Domenic> timbl: related to how GitHub URLs represent two things, the content in source control vs. a view of that content
18:38:33 <Domenic> timbl/wycats: e.g. when you hit the star button perhaps it should give you a choice which URL you want to "bookmark"
18:38:45 <Domenic> dka: why can't the app developer make this choice for you
18:38:55 <Domenic> wycats: because whichever choice they make will be wrong some of the time
18:39:04 <Domenic> JeniT: the user is the one who knows which is more interesting
18:39:23 <Domenic> JeniT: by the way, it's not necessarily a choice between two URLs, it's a choice between 1 ... Infinity
18:40:26 <Domenic> JeniT: this is all related to 209, but somewhat different
18:42:17 <Domenic> Discussion of whether HTTP 2 server push works...
18:43:10 <timbl> timbl has joined #tagmem
18:44:21 <Domenic> annevk: what do you expect a general purpose user agent to do with a 209?
18:44:34 <Domenic> annevk: probably nothing more than 200 so just use a custom header + 200
18:44:59 <Domenic> Yves: that might not be the case, e.g. images on mobile as an example
18:45:31 <Domenic> annevk: the consensus way forward for images is a type of content-negotiation approach
18:45:37 <Domenic> Yves: that has issues for caches
18:45:59 <Domenic> annevk: yeah, that's indeed a problem, but that's the way people are going
18:46:10 <Domenic> wycats: to me the biggest issue is that you only get one set of headers...
18:46:22 <annevk> It seems like Vary support will be something that's tackled sooner or later
18:46:57 <Domenic> wycats: what if you want to send headers talking about the original request instead of about the other resource
18:47:11 <Domenic> JeniT/timbl: then use 303; you can't do it with 209
18:47:36 <Domenic> Yves: you can insert headers into the Link header
18:47:39 <Domenic> wycats: seems bad?
18:47:53 <Domenic> Yves: less bad than 209
18:49:51 <Domenic> JeniT: I feel that the 209's use of Link header is not very accurate
18:51:03 <Domenic> Yves: 209 should be cached as a 200
18:51:23 <Domenic> timbl: because 209 is saying "pretend I was doing a 303 and gave you this"
18:53:31 <Domenic> annevk: reemphasizing that since it has no general-purpose semantics over 200 it should just be 200 + a special-purpose header
18:54:22 <Domenic> wycats: this is the kind of case where we use headers
18:54:30 <Domenic> Yves: headers don't modify the meaning of the reply
18:54:37 <Domenic> annevk: yes they do, e.g. Content-Type
18:54:47 <Domenic> timbl: no but Content-Type is *part* of the content
18:55:20 <Yves> the meaning of the reply as defined by the status code
18:55:52 <Domenic> Yves: clarifying--- tools that *don't* understand 209 will cache as 200
18:55:57 <Domenic> timbl: and we're ok with that!?
18:56:47 <Domenic> Yves: in general proxies will behave the same for any 2xx code (per HTTPbis) except partial content
18:57:28 <Domenic> wycats: if we're saying this is exactly the same as a 200 but with some special things for new clients, then why not put the new stuff in a header
18:58:08 <Domenic> annevk: the existence of other status codes is only there because they affect general-purpose clients
18:58:47 <Domenic> JeniT: what is the argument against using just a header?
18:59:05 <Domenic> Domenic: sounds like it's mostly a semantic argument about headers vs. status codes?
18:59:44 <Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6.3
19:00:45 <Domenic> wycats: the specific semantic web case seems different from the others
19:01:02 <Domenic> wycats: the semantic web case seems to need a new status code whereas the others remind me of things we already use headers for
19:01:14 <wycats> specifically things like Range and Content-Type
19:01:28 <Domenic> dka: to me it seems like two different problems; 209 may not make sense for browsable web
19:01:43 <Domenic> JeniT: I was sympathetic to that until I looked at the diagram opening my slides
19:02:31 <Domenic> JeniT: you could have various relationships not just "described by"
19:02:37 <Domenic> annevk: sounds like the Link header
19:02:55 <Domenic> timbl: then what do the other headers apply to
19:03:17 <dka> q?
19:03:20 <dka> q-
19:03:27 <Domenic> timbl: clarifying--- there are two types of headers, entity headers and non-entity headers
19:03:37 <dka> q+ to ask what the downside is of adding a status code…
19:03:38 <Domenic> timbl: examples of non-entity headers?
19:03:43 <Domenic> Yves: all the connection headers
19:04:28 <Domenic> dka: we've heard a lot of arguments saying "don't do 209"; what is the exact argument against it? Implementation-based or that it doesn't accomplish its job?
19:04:39 <dka> ack  e
19:04:41 <dka> ack me
19:04:41 <Zakim> dka, you wanted to ask what the downside is of adding a status code…
19:04:50 <Domenic> wycats: I think it's implementation based; its utility has not shown itself to be worth the implementation cost
19:05:29 <Domenic> wycats: remember that we don't want people to move from 200 to 209; we want people to move from 303 + 200 to 209
19:05:37 <Domenic> wycats: but remember that legacy infrastructure will not treat this the same way
19:06:42 <wycats> We want people to move from 303+200 -> 209, but they won't be able to move to 209 if they have to worry about legacy infrastructure
19:06:56 <Domenic> timbl: so how would the Link header version work?
19:07:00 <wycats> even though the behavior on legacy infrastructure is well-understood
19:07:16 <Domenic> annevk: clients who care would get the 200, look for the magic header (Link header?), and do the special processing.
19:07:56 <Domenic> annevk: Link rel="content-location" could do it
19:08:26 <Domenic> timbl: 209 is saying "the rest of the headers apply to the following, not the requested location"
19:08:34 <Domenic> wycats: only for new clients
19:09:11 <Domenic> Yves: no
19:09:15 <Domenic> timbl/wycats: yes
19:09:36 <Domenic> Yves: partial content use case
19:09:40 <Domenic> wycats: that's what the Range header is fgor
19:09:44 <Domenic> s/fgor/for
19:10:32 <Yves> Range header is only for 206
19:10:49 <Domenic> plinss: what about 309 instead of 209?
19:10:59 <Domenic> timbl/Yves: nope, 3xx content is about the redirect
19:11:08 <Domenic> timbl: no, 209 is better
19:11:41 <Domenic> plinss: but if we're relying on new clients to understand new semantics for the status code, 3xx would be better since it can fallback to 303
19:12:01 <Domenic> Yves: it should display as a 300, which gives the user a choice
19:12:03 <Domenic> JeniT: that's OK
19:12:03 <annevk> (I sort of feel like the HTTP WG would do a good job at shooting this down (or allowing it...) I'd rather work on something else)
19:13:46 <dherman> dherman has joined #tagmem
19:14:19 <Domenic> JeniT: 309 works well for headers
19:17:35 <Domenic> Action: Jeni to create a proposal documenting discussion (?)
19:17:35 <trackbot> Created ACTION-856 - Create a proposal documenting discussion (?) [on Jeni Tennison - due 2014-04-08].
19:18:58 <JeniT> slide outline was at: http://theodi.github.io/presentations/2014-04-01-http-209.html
19:50:54 <twirl> twirl has joined #tagmem
19:52:32 <timbl> timbl has joined #tagmem
19:54:23 <dka> Scribe: Jeni
19:54:28 <dka> ScribeNick: JeniT
19:54:32 <dka> Topic: TC39
19:55:05 <JeniT> dherman: the MS Word document that is the draft for ES6 hit the limits of MS Word
19:55:28 <JeniT> ... due to 11-bit limits on numbering schemes
19:56:12 <JeniT> slightlyoff: C++ is now HTML+GitHub
19:56:51 <JeniT> dherman: ISO & ECMA require MS Word
19:57:54 <JeniT> ... the temporary fix is to break up the document
19:58:08 <JeniT> ... this is part of a larger process problem
19:59:07 <JeniT> ... which also requires single editorship because of using Word
19:59:26 <JeniT> ... editors should be reviewing Pull requests & monitoring style etc, not doing all the writing too
19:59:57 <JeniT> ... we will need to generate a Word file, but we don't have to work with that during writing
20:00:16 <JeniT> slightlyoff: I suggest converting to PDF and importing one image per page into a Word file
20:00:23 <slightlyoff> e.g., the C++ spec: https://github.com/cplusplus/fundamentals-ts/
20:00:45 <JeniT> dherman: the source format needs to be inviting to web developers; we'll probably use Markdown to encourage contributions
20:01:03 <JeniT> timbl: which Markdown version?
20:01:20 <JeniT> wycats: GitHub version
20:01:57 <JeniT> dherman: each edition of the spec does have a major rewrite
20:02:28 <JeniT> ... there's a meta-language which is gradually getting more maintainable
20:03:03 <JeniT> ... that's the update on the process
20:03:22 <JeniT> wycats: we're moving to a new model where we work on features
20:03:40 <JeniT> ... where features can be implemented individually when they are ready
20:03:48 <JeniT> ... particularly where those features are isolated
20:04:24 <JeniT> ... we have got to an end of adding new features in ES6
20:04:36 <JeniT> ... we're moving towards writing it all down & getting it standardised
20:04:56 <JeniT> ... I've talked about classes & modules, which are both in
20:05:03 <JeniT> ... there's a thing called 'with' in JS
20:05:20 <JeniT> ... it introduces an object to the scope chain
20:06:04 <JeniT> ... what variables are in scope are a list of objects that are in scope
20:06:20 <JeniT> ... this causes problems when you add new properties on objects which exist on other objects
20:07:11 <JeniT> ... we'll add an 'unscopable' feature that stops the properties being visible using 'with'
20:07:24 <JeniT> annevk: this also matters for event handlers
20:08:03 <JeniT> wycats: basically don't use 'with'
20:08:16 <JeniT> ... new DOM APIs should add themselves to the unscopable list to avoid these clashes
20:08:20 <annevk> (What wycats is saying is that event handlers use the same model as with.)
20:08:35 <JeniT> ... modules are the biggest current issue
20:08:54 <JeniT> ... the way we factored the modules system is we created a delegation system from module loader to the network/file system layer
20:09:08 <JeniT> ... the module system doesn't know where it's getting the data from, it just knows that there is a way to get content
20:09:41 <JeniT> dherman: there's always been a split between ES semantics & browser semantics
20:09:52 <JeniT> ... modules touch on both
20:10:11 <JeniT> ... how the bits get fetched for modules is on the browser side
20:10:48 <JeniT> ... if you're doing ES server-side you have one way of saying where the modules come from
20:11:02 <JeniT> ... but if you're doing it on the browser, you have to say how module names get mapped to URLs to fetch the code
20:11:14 <JeniT> ... that has to be specced outside TC39
20:11:21 <JeniT> plinss: who's working on this?
20:11:25 <JeniT> dherman: wycats and I
20:11:33 <JeniT> timbl: do relative URLs work?
20:11:46 <JeniT> dherman: that's tricky wrt compatibility with existing module systems
20:11:57 <JeniT> ... ie node/npm and XXX
20:12:12 <annevk> s/XXX/AMD/
20:12:29 <JeniT> wycats: absolute lookup on the file system is different from what it means on the web
20:12:38 <JeniT> ... on the file system it's a scan
20:13:01 <JeniT> timbl: all the programming languages I've used that have class paths etc that get scanned, it's always caused pain
20:13:19 <JeniT> wycats: Node doesn't quite work like that
20:13:35 <JeniT> ... it's supposed to look in the current directory
20:13:47 <JeniT> dherman: we don't have to make any design decisions about that
20:14:05 <JeniT> ... it's up to whoever creates a JS engine
20:14:24 <JeniT> timbl: I want to create HTML+JS and package it *
20:14:31 <JeniT> ... & put it on a web server
20:14:51 <JeniT> wycats: the browser loader will work like that, but Node should also be able to evolve into the ES6 module system
20:15:05 <JeniT> ... there is a loader abstraction that enables the environment to decide how to do it
20:15:18 <JeniT> ... we've talked about making the ES spec more specific about what that means
20:15:42 <JeniT> ... getting the browser and Node to be compatible is hard work
20:16:00 <dka> dka has joined #tagmem
20:16:11 <JeniT> ... the module syntax & loader abstraction should make it possible to work on the web and in Node without moving files around
20:17:00 <JeniT> dherman: there's the syntax of the module that you write, which we want to be portable
20:17:09 <JeniT> ... then there's package management systems, which are out of scope
20:17:32 <JeniT> ... we're not trying to create workflows that say 'here's how you register packages for other people to download'
20:18:31 <JeniT> ... the lookup semantics (eg package registry) is out of scope
20:19:29 <JeniT> timbl: you should be able to use an absolute URI to refer to an npm module, not have to point to npm
20:19:51 <JeniT> Domenic: is the issue does Node want to be able to point to absolute URLs for modules?
20:20:25 <JeniT> timbl: suppose someone else created their own repository for Node modules (eg because they were specialised)
20:20:40 <JeniT> ... you want to be able to point to those modules with an absolute link
20:20:53 <JeniT> dherman: that's the design of the package system, which aren't in scope
20:21:45 <JeniT> ... you could design something like npm or design a different system
20:22:16 <JeniT> ... we can build a sensible set of defaults for the browser loader
20:22:24 <JeniT> ... so you can download the source from a specific HTTP URL
20:22:31 <JeniT> ... and that makes sense for relative URLs within a given server
20:22:44 <JeniT> ... all the configurability of the system will allow for experimentation on that default policy
20:22:55 <JeniT> ... so people could develop their own package management ecosystems
20:23:00 <JeniT> ... that's a community building process
20:23:25 <JeniT> slightlyoff: trying to do this for the browser is likely to create something that won't work for other environments
20:23:39 <JeniT> wycats: the greatest success will be if many modules are written for both the browser and for Node
20:23:56 <JeniT> ... we need to start with small evolutionary steps that enable experimentation
20:24:07 <JeniT> timbl: my students have to write for both
20:24:14 <JeniT> Domenic: I think that happens in lots of places
20:24:49 <JeniT> slightlyoff: the two environments (browser vs server) are completely different (eg CPU)
20:25:23 <JeniT> ... our experience is that there are small bits of code that you will want to move, but they're the exception rather than the rule
20:25:39 <JeniT> wycats: they may be the exception but they're extremely valuable
20:26:16 <JeniT> slightlyoff: Node running on your local computer vs Node running in a browser are very different
20:26:36 <JeniT> twirl: we write code that works on both, particularly models
20:26:54 <twirl> s/models/modules
20:26:58 <JeniT> wycats: I hope is that we'll have a system that *allows* people to write modules that can be deployed in both environments
20:27:44 <JeniT> dherman: the module tag
20:27:49 <JeniT> slightlyoff: cannot be the module tag
20:27:52 <JeniT> dherman: oh yes it can
20:27:55 <JeniT> slightlyoff: oh not it can't
20:28:00 <slightlyoff> FIGHT FIGHT FIGHT
20:28:17 <JeniT> dherman: the new module system has to have an end-to-end process that makes sense
20:28:45 <JeniT> ... there needs to be a good way to kick off your application, to write your main driver code embedded in HTML
20:28:54 <JeniT> wycats: like the main() function
20:29:03 <JeniT> dherman: there's a bootstrapping problem
20:29:21 <JeniT> ... you can say system.import that gives you a promise
20:29:26 <JeniT> ... but that's a very low level approach
20:29:43 <JeniT> ... we want a declarative approach to avoid boilerplate etc
20:30:04 <JeniT> ... we want people to say 'import' in their top-level code, but it needs to be asynchronous
20:30:18 <JeniT> ... so the design of the module system is that the import syntax can only be used in an environment that's asynchronous
20:30:35 <JeniT> ... ES6 doesn't allow you to say import except inside a module
20:30:51 <JeniT> ... module can only be run in asynchronous environments
20:31:01 <JeniT> ... in Node you might relax that
20:31:23 <JeniT> ... we want people to be able to say import but you can only do that in a module
20:31:30 <JeniT> ... you can't do that in a script tag
20:31:51 <JeniT> ... which puts you in the global scope, polluting the global namespace
20:32:15 <JeniT> ... we want a new tag that gives a clean end-to-end story
20:32:22 <JeniT> ... where temporary variables are entirely local
20:32:28 <JeniT> ... where you can use the declarative import form
20:32:35 <JeniT> ... and where it's asynchronous by default
20:32:40 <JeniT> ... the <module> tag is all these things
20:32:48 <JeniT> ... it declares an anonymous module
20:32:57 <JeniT> ... it has the same semantics as script defer
20:33:01 <Domenic> https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md
20:33:30 <JeniT> ... there are various evolutionary parts of the story where we have to make a transition story where module has to work in legacy browsers
20:33:43 <JeniT> ... it has to be implicitly CDATA
20:33:46 <Domenic> https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md#how-do-we-get-there-from-here
20:34:16 <JeniT> dherman: the stopgap is a new script type
20:35:04 <JeniT> JeniT: why would anyone move to <module> then?
20:35:07 <JeniT> dherman: because it's short
20:35:43 <JeniT> ... shorter than <script type="application/javascript+module">
20:35:56 <JeniT> Yves: you could have another attribute that's the trigger
20:36:16 <Domenic> <script m>?
20:36:20 <wycats> <module> is still shorter than <script module>
20:36:23 <JeniT> timbl: <sarcasm>are you saying that you want to add a whole new tag to HTML? that should be a high bar!</sarcasm>
20:36:36 <wycats> also <script module> is confusing because JS has "scripts" and "modules"
20:36:44 <Domenic> +1 to wycats
20:36:47 <slightlyoff> Domenic: I like <script m>
20:36:55 <slightlyoff> OR
20:36:57 <wycats> <em script em>?
20:37:02 <slightlyoff> the canadian version:
20:37:04 <slightlyoff> <script eh>
20:37:21 <wycats> I learned that <script |foo|> is totally valid HTML
20:37:23 <JeniT> dherman: one of the reasons I ran for the TAG is that the development story is really important
20:37:43 <JeniT> ... when it comes to modules and imports, it's so central to how people develop web applications
20:37:54 <JeniT> ... we need to make sure the workflow is as seamless as it is in Node
20:38:05 <JeniT> ... it's important that the ergonomics are extremely cheap
20:38:21 <JeniT> twirl: what are the arguments against the <module> tag?
20:38:35 <JeniT> slightlyoff: it's not against the <module> tag, it's about the incentives of what sites are likely to do
20:38:54 <JeniT> ... it's reasonable to assume that security-conscious sites won't use it until all clients can support it
20:39:15 <JeniT> dherman: those sites already leave script off their whitelist
20:39:33 <JeniT> slightlyoff: I don't think we'll see broad use of <module> for a long time
20:39:44 <slightlyoff> (agreement in the room)
20:39:57 <JeniT> wycats: yes, that's the plan; we know that old browsers don't get supported forever
20:40:08 <JeniT> slightlyoff: GoogleApps only support one version back
20:40:40 <JeniT> wycats: we know for sure that people eventually drop IE6 & 7
20:41:09 <JeniT> ... we used to think people supported old browsers forever, but they don't
20:42:10 <JeniT> annevk: what's the API? <script> & <module> aren't interchangeable
20:42:35 <JeniT> slightlyoff: the attributes will have different defaults depending on which you use
20:42:49 <JeniT> Domenic: on the <script> tag will the attributes be ignored?
20:42:52 <JeniT> dherman: yes, I think
20:43:16 <JeniT> wycats: we won't need attributes on the <module> tag
20:43:28 <JeniT> slightlyoff: you will need async
20:44:03 <JeniT> ... we need to add script with content and defer=true
20:44:48 <JeniT> slightlyoff: I'd like to raise the topic of ordering in general
20:45:01 <JeniT> ... modules don't solve this because there are lots of other things you care about
20:45:45 <JeniT> wycats: there's a meta problem about staging on the web, which we've done a good job on with modules
20:45:54 <JeniT> ... which we need to link up with HTML
20:46:14 <JeniT> dherman: if you have reflective APIs that let you change the way the semantics of something
20:46:25 <JeniT> ... eg in the module system, how module names get resolved
20:46:34 <JeniT> ... there's a compile time stage & a runtime stage
20:46:53 <JeniT> ... if you want the runtime of some code comes before the compile time of another, you need to be able to say that
20:47:02 <JeniT> ... custom elements do this as well for example
20:47:11 <JeniT> wycats: and ServiceWorker
20:47:26 <JeniT> dherman: all these things need to have control over ordering
20:47:38 <JeniT> Domenic: how does modules solve this problem?
20:48:02 <JeniT> dherman: the defer semantics ensures that one tag happens before the other, they're guaranteed in order
20:48:21 <JeniT> ... it's straightforward, you don't need deep or subtle understanding
20:48:33 <JeniT> wycats: in JS there's design time & runtime
20:48:54 <JeniT> Domenic: in custom elements, you want to run some code guaranteeing it had been registered
20:49:14 <JeniT> ... I would prefer to solve this with the module system rather than using HTML imports
20:49:36 <JeniT> dherman: you want to finish the execution stage before you do the HTML stuff
20:49:46 <JeniT> ... this is a multi-stage dependency between script & HTML
20:49:59 <JeniT> Domenic: if you're only doing stuff in script it's simple
20:50:09 <JeniT> wycats: the problem is you have HTML in the body tag
20:51:33 <JeniT> [discussion about upgrades in web components]
20:51:51 <JeniT> dherman, wycats: upgrades have been dropped
20:51:57 <JeniT> slightlyoff: we need them!
20:52:33 <Domenic> http://w3c.github.io/webcomponents/spec/custom/#registering-custom-elements
20:52:52 <Domenic> The spec says they have not been dropped
20:53:12 <JeniT> dka: are we still talking about TC39?
20:53:34 <JeniT> Domenic: we've transitioned a bit to staging as it applies to web components
20:53:46 <JeniT> dherman: we're talking about the system being self-modifiable
20:54:07 <JeniT> ... you can work purely in the reflective API
20:54:17 <JeniT> ... but you want a declarative way to do that
20:54:27 <JeniT> ... you have to make it clear that one thing happens before another
20:54:34 <JeniT> wycats: a problem with upgrades is unresolved CSS
20:54:47 <JeniT> ... people want to not put stuff on screen until you know what they look like
20:55:10 <JeniT> ... the way upgrade works is that you put it in as a normal HTML element, and eventually you replace it when the code comes in
20:55:17 <JeniT> ... this won't give the UI that people want
20:55:25 <JeniT> ... there's the unresolved CSS class to hack around this
20:55:43 <JeniT> ... I think people will want to mark HTML as stuff not to be processed until it's ready
20:55:47 <JeniT> ... and there's no way to do that yet
20:56:40 <JeniT> Domenic: they will have the correct behaviour by the time the code needs to reason about them
20:57:10 <JeniT> plinss: what's the unresolved CSS class?
20:57:23 <JeniT> ... it needs to be a pseudo class, it needs to be known by the CSS WG
20:58:10 <JeniT> Domenic: you could use code to prevent stuff showing before you're ready for it
20:58:27 <JeniT> dherman: yes, you can do that in the reflective layer, but we need to have something declarative
20:58:42 <JeniT> slightlyoff: you can use CSS for this, to prevent rendering
20:59:10 <JeniT> ... there are two trees: the DOM tree & the render tree, the only thing that affects the render tree is CSS
20:59:29 <JeniT> wycats: you might want to have a blocking script that isn't blocking
20:59:43 <JeniT> Domenic: you want a module src with an attribute that says don't render at all
20:59:52 <JeniT> slightlyoff: this is why I keep talking about dependencies
21:00:00 <JeniT> ... we have no system for dependencies
21:00:09 <JeniT> wycats: you need to say body tag depends on *this thing*
21:01:03 <slightlyoff> scribenick slightlyoff
21:01:22 <slightlyoff> dka: I'm hearing tension between some of this and other development best practice...how do we resolve this?
21:01:53 <slightlyoff> dherman: there _is_ tension between processing ordering and extensibility. It's important to reflectively be able to modify, but also pave those paths to enable ways out of the imperative world
21:02:04 <slightlyoff> dherman: we're going to have to find ways to optimize some of these things
21:02:10 <slightlyoff> (integrity URLs are promising)
21:02:29 <slightlyoff> Domenic: going async first is good because it allows you to synchronize in userspace
21:02:53 <slightlyoff> dherman: thats' a good point...that lets you drop down to let you be concurrent when you want to be
21:03:48 <slightlyoff> Domenic: previous solutions with dependencies are very much like programming...if we say that the declarative level is for people who don't need all the perf benefits, that's fine
21:03:52 <slightlyoff> slightlyoff: disagree!
21:04:20 <JeniT> slightlyoff: in most systems that are going to go fast, declarative constraints allow you to optimise in ways when you first build the system
21:04:34 <JeniT> ... it's worthwhile not treating declarative forms as second class systems
21:04:41 <JeniT> ... it's a misappropriation of incentives
21:04:56 <JeniT> ... we should be prioritising both for development & performance the good practices
21:05:03 <slightlyoff> (back as scribe)
21:05:11 <JeniT> s/.../dherman
21:05:31 <slightlyoff> wycats: we can do a first approximation as an imperative level, add a second version which is a declarative layer, and then turn the crank
21:05:50 <slightlyoff> Domenic: I can't see a way to provide enough levers without turning it into programming
21:06:45 <slightlyoff> dherman: I can think of some tricks; e.g., lets say you want to provide some optimizations around configurable loaders. THere's a default around resolving names. You might do it in such a way that the browser prefetch runs ahead and when it knows it doesn't know what to do, doeesn't try to prefetch.
21:07:20 <slightlyoff> dherman: so you can do things where delcarative forms enable optimizations and if you extend in ways that are compatible, you can preserve the optimization.
21:08:34 <slightlyoff> wycats: I don't think we can design this. If people like getify or jburke want to go out and define it, we should try to pave that cowpath
21:08:56 <slightlyoff> Domenic: slightlyoff, do you remember when you proposed controlling rendering?
21:09:37 <slightlyoff> Domenic: the idea was that you'd be able to control when things are rendered (painted), and once you got to some point, you could put the browser back in the default rendering mode
21:10:26 <slightlyoff> slightlyoff: I'd like to consider this in context of rehabilitating CSS
21:11:09 <Zakim> Zakim has left #tagmem
21:11:19 <slightlyoff> Domenic: should we invite folks to this meeting?
21:11:27 <Zakim> Zakim has joined #tagmem
21:11:40 <slightlyoff> dherman: the servo folks have done a lot of good layering of the rendering stack. Involving them might be good.
21:12:37 <slightlyoff> wycats: you sort want to control rAF, right? You want to prevent draw calls between your paint and your rAF timer. Lots of code breaks these invariants and cause reflows
21:12:45 <slightlyoff> wycats: we need good tools
21:13:04 <JeniT> slightlyoff: there are distinct phases of rendering that are worth considering
21:13:26 <JeniT> ... the way to think about the DOM vs render tree distinction is that a good browser will turn the DOM into a render tree, and then apply CSS rules to it
21:13:37 <JeniT> ... once you go from DOM to parsed CSS, that's hands off
21:13:52 <JeniT> ... you could imagine there was a worker created for every document
21:14:06 <JeniT> ... that took the DOM tree & turned it into render tree
21:14:31 <JeniT> ... requestAnimationFrame might be usable
21:15:01 <slightlyoff> you can imagine that there's a worker that owns the render tree
21:15:06 <slightlyoff> and that all painting would happen from that worker
21:15:36 <slightlyoff> the paint calls themselves can conceptually come from that worker and the render tree would be owned by that worker
21:15:51 <slightlyoff> today we can't reason about that world
21:15:57 <slightlyoff> dka: this all sounds theoretical
21:16:47 <slightlyoff> wycats: I agreed with you, dka, until I had a meeting with (googlers) where I realized that we can't keep punting on CSS...it keeps tripping us up
21:17:19 <slightlyoff> dherman: everyone I talk to who thinks about the extensibility of CSS keeps zeroing on the same solution: messages to a worker, etc.
21:17:40 <slightlyoff> dherman: and I want to get servo in on this conversation so we're not hostile to parallelism
21:18:17 <JeniT> slightlyoff: there's a worker that controls paint, also a worker that controls GPU
21:18:31 <JeniT> dka: isn't that a differentiator between browsers?
21:18:56 <slightlyoff> plinss: there are lots of these features which are getting added which relate to these GPU layers
21:19:06 <slightlyoff> plinss: this is now part of the CSS declarative world
21:19:16 <slightlyoff> plinss: it's implied by the CSS but isn't defined by it
21:19:32 <slightlyoff> plinss: I've been saying for 15 years that we need to define the rest of the rendering model of the web browser
21:19:38 <slightlyoff> plinss: we need to have a rendering layer for the API
21:20:08 <slightlyoff> plinss: you'll find a resolution in the CSS WG a couple years ago for "less magic"
21:20:30 <slightlyoff> wycats: I think that there are some structures that are common across browsers is a good basis for standardizing something
21:20:47 <slightlyoff> dherman: this is one of the places where, for implementers, the Extensible Web is a very scary thing
21:20:53 <slightlyoff> dherman: and you have to find the right layer of abstraction
21:21:02 <slightlyoff> dherman: servo might be useful because it's taking a more different approach
21:22:25 <slightlyoff> wycats: I think Elliot Sphren was taking an extreme view that we shouldn't expose thigns that don't have C++ behind them today
21:22:36 <slightlyoff> plinss: and the counter is that we need to expose some layers
21:23:05 <slightlyoff> wycats: I don't think we should just expose the C++ guts, but that everyone has something similar means we should be able to get something done
21:24:04 <slightlyoff> Topic: servo intro
21:24:56 <slightlyoff> dherman: servo is a new browser rendering engine being developed by Mozilla Research based on Rust, a new language also being developed by Mozilla Research
21:25:20 <slightlyoff> dherman: it's the most extensible-webby thing next to Bravo, but it's still being built in a low-level language (Rust)
21:25:43 <slightlyoff> dherman: it's designed to provide comprable performance to C++
21:25:52 <slightlyoff> dherman: the 2 goals are safety and paralleism
21:26:12 <slightlyoff> dherman: we're looking for every possible trick we can pull with regards to modern hardware; what can we do on the GPU, SIMD, advanced experiments
21:26:36 <slightlyoff> dherman: one of the main goals of paralleization is to allow script to usually be running in the background
21:26:52 <slightlyoff> dherman: the status is that we just passed Acid2 last week
21:27:03 <slightlyoff> (discussion of cakes, which appear to be important to browser people)
21:27:18 <slightlyoff> dherman: we render wikipedia, reddit...important sites
21:27:34 <slightlyoff> dherman: we can render cross-origin iframes in separate threads, also <iframe sandbox>
21:28:12 <slightlyoff> dherman: it's a way to guarantee that you've got better security
21:28:25 <slightlyoff> dherman: we've tried to put bugs in individual components to show that there's isolation
21:28:38 <slightlyoff> dherman: when you're doing parallelism you have to do much cleaner tree traversals
21:29:00 <slightlyoff> dherman: fewer special cases, which leads to better maintainability
21:29:36 <slightlyoff> dherman: floats are incredibly damaging to parallelism
21:29:42 <slightlyoff> they cause us to fall back on a sequential path
21:29:57 <slightlyoff> dherman: we discovered the clear: both is basically a parallelization hint
21:30:06 <slightlyoff> wycats: what about overflow: hidden?
21:30:07 <slightlyoff> dherman: dunno
21:30:22 <slightlyoff> dherman: we're looking for opportunities to parallelize
21:30:36 <slightlyoff> timbl: there are ways we can encourage people to do the right thing?
21:30:46 <slightlyoff> dherman: our ideal goal is to run existing content faster
21:30:56 <slightlyoff> dherman: we want to beat existing engines all the time
21:31:10 <slightlyoff> dherman: but if we can show people patterns that will let their code go faster, that'd be good too
21:31:34 <slightlyoff> dherman: that means existing content won't get the full benefits, but we can help people get all the benefits with tools
21:31:42 <slightlyoff> wycats: yes, we see this with chrome
21:31:55 <JeniT> "we shape our tools and our tools shape us"
21:32:06 <slightlyoff> dherman: the third level is to identify inherent problems with the platform where we say "we need something new"
21:32:13 <slightlyoff> wycats: floats suck, what about flexbox?
21:32:38 <slightlyoff> dherman: patrick has his eye on what's terrible in the proposals for CSS
21:33:09 <slightlyoff> dherman: one of the reasons I want him at the EWS is to help advocate against things that will screw performance
21:33:24 <slightlyoff> wycats: I'm interested in ensuring that flexbox and grid layout dont' cause extra problems
21:33:36 <slightlyoff> dherman: he was talking about not wanting selector matching to crate nodes in the flow tree
21:33:52 <slightlyoff> dherman: I think he's decided that pseudo elements...generated content...
21:33:59 <slightlyoff> wycats: ::first-line()
21:34:07 <slightlyoff> (counters, ::before, ::after)
21:34:32 <slightlyoff> dherman: I think that we've made peace with ::before and ::after...
21:34:37 <slightlyoff> (discussion of decorators)
21:35:48 <slightlyoff> dherman: the last point, tying this back to extensible web, even though we're not self-hosting it all in JS, we've been pretty principled about layers of abstraction and modularization and that could inform future extensibility projects
21:36:15 <slightlyoff> dherman: I also expect taht a lot of what we're doing could also self-hosted with web components (assuming they have true information hiding)
21:36:24 <slightlyoff> wycats: would be great if Servo led the way there
21:36:54 <slightlyoff> wycats: it might be nice if Servo were prioritizing things like SW so that others can help self-host
21:37:08 <slightlyoff> (discussion of implementation priorities)
21:38:00 <slightlyoff> (discussion of schedule and needs)
21:38:20 <slightlyoff> dherman: have discussed web components + self hosting with Samsung partners
21:38:56 <slightlyoff> (discussion of XUL history)
21:40:30 <slightlyoff> twirl: is this going to replace JagerMonkey
21:40:31 <slightlyoff> ?
21:40:38 <slightlyoff> dherman: this won't replace the JS engine
21:40:55 <slightlyoff> dherman: but we have the oilpan approach of a single memory system
21:41:21 <slightlyoff> dherman: largely because Rust has an extensible idea of pointers and memory management
21:42:01 <slightlyoff> (dherman's C++ smells like lisp)
21:42:42 <wycats> dherman: you never need to learn the new names - it's all Spidermonkey
21:42:51 <slightlyoff> at some point we might need something new, but that's a long way off
21:43:16 <slightlyoff> dherman: as far as Gecko, considering replacing it with Servo, we don't have plans to replace it in the Desktop browser
21:43:36 <slightlyoff> dherman: we, by design, don't have XPCom in FFOS and that will work better with Servo
21:43:49 <slightlyoff> dherman: add-on compatibility constrains the desktop browser
21:44:43 <slightlyoff> (discussion of next topic)
22:07:10 <Domenic> http://prospectsf.com/menus.html
22:10:53 <slightlyoff> (break)
22:14:30 <slightlyoff> Topic: CSS excavation
22:14:51 <slightlyoff> Domenic: (potential issues/topics)
22:15:03 <Domenic> - Custom everything
22:15:03 <Domenic> - Rendering tree primitives
22:15:03 <Domenic> - Web animations
22:15:03 <Domenic> - Revamped CSSOM?
22:15:03 <Domenic> - how this all tied up in shadow DOM
22:15:07 <slightlyoff> thanks!
22:15:46 <dka> Topic: “CSS Archeology”
22:15:47 <slightlyoff> annevk: Shadow DOM is a way to extend the rendering tree, correct?
22:16:22 <slightlyoff> wycats: Googlers told me that Shadow DOM is the smallest thing they could think of that creates rendering isolation from the parent and allows you to avoid styling children by default
22:16:44 <slightlyoff> wycats: the way it works is that "there's no parent", which means that child selectors/propagation braks
22:17:09 <slightlyoff> wycats: there's no basic, smaller things that achieves those goals (says them)
22:17:29 <slightlyoff> Domenic: this seems to tie into the fact that the DOM and Render trees are coupled today
22:17:32 <slightlyoff> slightlyoff: are they?
22:17:41 <slightlyoff> annevk: DOM tree begets layout tree
22:18:11 <slightlyoff> annevk: the event model is layered on top of it
22:18:40 <slightlyoff> slightlyoff: re-targeting, something browsers already do in other areas
22:18:50 <slightlyoff> wycats: the declarative coupling is convenient
22:19:05 <slightlyoff> Domenic: people talk to me about "lightweight boxes"....boxes are different than elements
22:20:28 <slightlyoff> slightlyoff: (explains the set of boxes that CSS creates)
22:20:41 <slightlyoff> Domenic: would it be useful to create simple boxes?
22:20:45 <slightlyoff> plinss: yes
22:20:51 <slightlyoff> slightlyoff: yeah, how does CSS work?
22:21:01 <slightlyoff> plinss: any given element can have 0 to N boxes
22:21:10 <slightlyoff> plinss: we're trying to clean up the terminology
22:21:16 <slightlyoff> plinss: multiple boxes map to a single DOM node
22:22:10 <slightlyoff> slightlyoff: "display: block" elements have different nodes
22:22:18 <slightlyoff> s/nodes/boxes and relationships/
22:22:33 <slightlyoff> Domenic: I've heard many people talk about the real primitive is WebGL
22:22:44 <slightlyoff> (issues are acknowledged)
22:23:06 <slightlyoff> (discussion of conflation about "element", "box", and "block")
22:23:43 <slightlyoff> timbl: CSS has lots of boxes, but not a lot of "glue"...in TeX you can give things units that can be distributed
22:23:51 <slightlyoff> plinss: we have that in calc()
22:24:09 <slightlyoff> plinss: each box has min-width, max-width, intrinsic-width, etc.
22:24:23 <slightlyoff> plinss: answering the question "how wide would this like to be?" and "how small can it possible be?"
22:24:34 <slightlyoff> (miminmum intrinsic width, maximum intrinsic width)
22:24:49 <slightlyoff> plinss: we have the notion of the value of the width being "3em + 20%"
22:25:04 <slightlyoff> plinss: there is the notion of "as wide as I need to be + 10px"
22:25:49 <slightlyoff> wycats: the iOS stuff makes it very hard to do good layout..the web makes it much easier
22:26:15 <slightlyoff> wycats: people who build things often forget about default text sizing
22:26:26 <slightlyoff> plinss: a lot of what browsers do is "auto"
22:26:49 <slightlyoff> wycats: I used to work on SproutCore, and it was good for positioning UI elements but not for laying out text
22:27:20 <slightlyoff> timbl: if you could subclass a box...you could make different approximations to a "pain function"
22:27:39 <slightlyoff> timbl: it could get very complicated...would layout engines become impossible?
22:28:28 <slightlyoff> plinss: there are lots of page layout problems where it's impossible to get out of situations that iterate without breaking the cycles
22:28:48 <slightlyoff> plinss: you wind up creating abox tree, doing recursive descent and boxes might depend on their children's properties
22:29:14 <slightlyoff> plinss: you wind up, generally, going to the bottom, going back up, doing placement of children relative to parents (which then informs parent layout)
22:29:25 <slightlyoff> wycats: what's an evolutionary path
22:29:26 <slightlyoff> ?
22:29:42 <slightlyoff> Domenic: one thing I remember...getBoundingQuads() or something was just added
22:29:55 <slightlyoff> (more powerful than getBoundingClientRects())
22:30:08 <slightlyoff> s/getBoundingQuads/getBoxQuads/
22:30:09 <annevk> Domenic: http://dev.w3.org/csswg/cssom-view/#dom-geometryutils-getboxquads
22:30:16 <Domenic> https://hacks.mozilla.org/2014/03/introducing-the-getboxquads-api/
22:30:37 <slightlyoff> (discussion of getBoundingClientRects() and xforms)
22:30:38 <annevk> (CSS WG style sheet is super annoying today due to April 1)
22:30:53 <slightlyoff> today? really? thats' the reason? ;-)
22:31:39 <slightlyoff> dherman: layout api vs. DOM API: do we want a mirror approach where you an say "from this DOM node, get the layout object"?
22:31:47 <slightlyoff> (where that would be async)
22:32:20 <slightlyoff> dherman: that'd give us a separate space where you'd be able to consider layout
22:32:40 <slightlyoff> plinss: are you talking about mutation of the box tree? or the layout tree? both of those need to be under the control of the layout engine
22:33:47 <slightlyoff> (we noted that getBoxQuads() is a new sync API)
22:34:04 <slightlyoff> wycats: we now have a foot machine-gun
22:34:21 <slightlyoff> Domenic: is it our job to condemn specific APIs?
22:34:23 <slightlyoff> (YES)
22:35:11 <slightlyoff> (discussion of computed style, how the Dart DOM avoided synchronizing on layout)
22:35:42 <slightlyoff> plinss: we've conflated layout, style, and DOM into the DOM APIs...we need to break them out
22:35:52 <slightlyoff> (discussion of mirror API)
22:36:41 <slightlyoff> plinss: we should have the DOM API, the box tree API, and a rendering API
22:37:01 <slightlyoff> plinss: people would love to be able to do grid layout as a polyfill
22:37:25 <slightlyoff> plinss: you can imagine firing events and workers where it's sending information in it's traversal
22:37:36 <slightlyoff> plinss: the contexts need to be bounded...
22:37:52 <slightlyoff> plinss: the JS can't go inserting DOM nodes when we're doing the layouts
22:38:15 <slightlyoff> wycats: one thing we can do is xform the getBoxQuads() to be async
22:38:43 <slightlyoff> wycats: we need these thigns because hit testing
22:39:26 <slightlyoff> (discussion of async/post-layout)
22:39:35 <slightlyoff> plinss: what about CSS animations and transitions?
22:39:56 <slightlyoff> dherman: this is an extrememly racey concept
22:40:14 <slightlyoff> dherman: we've got a mutable representation and we're asking to iterleave things
22:40:28 <slightlyoff> dherman: how do you do this sort of thing in practice?
22:40:37 <slightlyoff> dherman: the blocking API makes this non-racy
22:40:51 <slightlyoff> wycats: I keep bringing this in TC39: we create buckets
22:41:23 <slightlyoff> dherman: so its' a racey platform and you impose synchronization
22:41:24 <slightlyoff> ?
22:41:27 <slightlyoff> wycats: yes
22:41:58 <slightlyoff> Domenic: most recently I used getClientBoundingRect() was for positioning a popup in response to a user click
22:42:07 <annevk> I'm not sure to what extent this is important, but transforms and such do not actually affect layout at the moment. So the boxes getBoxQuads returns are not all layout boxes as I understand it.
22:42:08 <slightlyoff> Domenic: the delay for promise deliery was fine
22:42:42 <slightlyoff> annevk: even worse...you might need readback from the GPU = (
22:43:07 <annevk> slightlyoff: if painting happens there...
22:43:14 <slightlyoff> wycats: setImmediate has been busted in IE for a while, and one of the thigns that came up was a clear realization that you want to run something before something else
22:43:23 <slightlyoff> wycats: you wnat to run before/after GC (e.g.)
22:43:26 <annevk> slightlyoff: or a special path I suppose that makes the calculations
22:43:31 <slightlyoff> wycats: the thing people do is to hackity-hack-hack
22:43:43 <slightlyoff> annevk, we need a new worker type
22:44:04 <slightlyoff> dherman: I have a really hard time trying to understand how that'd work in the competitive browser environment + standards
22:44:14 <slightlyoff> wycats: you create buckets, name them well
22:44:24 <slightlyoff> (not "beforeGC")
22:44:47 <slightlyoff> (discussion of transform(0) hack)
22:45:29 <slightlyoff> wycats: if you only give people sledgehammers, they eventually end up swinging sledgehammers and browsers have to take them away
22:45:45 <slightlyoff> (discussion of naming )
22:46:14 <slightlyoff> scribe peroggative = )
22:46:47 <slightlyoff> discussion of putting "random order" in a spec
22:47:22 <slightlyoff> wycats: it'd be good if we gave developers tools that let them control how they synchronize
22:49:01 <Domenic> slightlyoff: access to layout information sync on the main thread is bad. But there may be a thread where it is already cheap.
22:49:19 <Domenic> You could model async access to the layout info as essentially a postMessage from the layout thread to the main thread
22:49:36 <Domenic> slightlyoff: the object models in those two threads may be wildly different
22:50:47 <slightlyoff> s/layout thread/input thread/
22:51:16 <slightlyoff> the threads are roughly: main thread (JS/DOM), render thread (box tree), and input thread (layers, raw input)
22:53:11 <slightlyoff> (discussion of Promises vs. async function model for description, clarification of execution model)
22:53:52 <slightlyoff> (noting that await makes message passing much nicer)
22:53:55 <slightlyoff> (digression)
22:54:35 <slightlyoff> wycats: the current state of workers makes them hard
22:54:45 <slightlyoff> annevk: can we add a worker element?
22:54:52 <slightlyoff> <worker>
22:54:58 <slightlyoff> (what does it do?)
22:55:11 <slightlyoff> it's declarative!
22:55:31 <slightlyoff> Domenic: so instead of "new Worker(url)"...
22:55:50 <slightlyoff> wycats: no! you have to do a data url from a blog
22:55:53 <slightlyoff> s/blog/blob/
22:56:32 <annevk> s/data url/blob url/
22:56:36 <slightlyoff> dherman: so the key difference between your model and what I noted is that you're proposing running code on a totally different element?
22:57:06 <slightlyoff> <note that you could now postMessage() to this the way iframes do this)
22:58:24 <slightlyoff> annevk: if <script> has the document context and <module> has the module context, this makes sense...
22:59:32 <slightlyoff> (discussion of setup of these sorts of contexts in the document)
23:00:05 <slightlyoff> annevk: how will we polyfill sync things on top of this?
23:00:23 <slightlyoff> annevk: what about offsetWidth?
23:01:27 <slightlyoff> (some discussion of how bad those APIs are and how we might try to turn them down)
23:01:53 <slightlyoff> Domenic: to make all of this soemthing ew're spending time on, we should find a way to model useful things via this model
23:02:17 <slightlyoff> Domenic: we need things other than hit testing as a use-case
23:02:47 <slightlyoff> annevk: if the layout tree is in the worker, what does that mean (e.g.) for mouse events?
23:03:08 <slightlyoff> slightlyoff: who says tht the box tree has events dispatched against it?
23:03:48 <slightlyoff> (discussion of propagation..DOM vs. box tree)
23:04:04 <slightlyoff> (discussion of :hover)
23:06:42 <slightlyoff> (dicussion of how to map render item back to the DOM item)
23:06:56 <slightlyoff> annevk: we need to have a conceptual model of how event dispatching would work
23:07:35 <slightlyoff> slightlyoff: the trees aren't 1:1
23:07:49 <slightlyoff> slightlyoff: stacking contexts are going to change things in the render tre
23:07:50 <slightlyoff> tree
23:08:11 <slightlyoff> plinss: you're going to need to have some read operations, like text for content
23:08:51 <slightlyoff> (note that the <canvas> element has a text measurement API)
23:09:12 <slightlyoff> slightlyoff: it's not good...doesn't do layout in the context of an element's cascade, doesn't do it async, etc.)
23:09:18 <twirl> (which doesn't work properly)
23:09:54 <slightlyoff> Domenic: as a first pass, maybe we can build a promise-based async api that works on this other tree
23:10:16 <slightlyoff> Domenic: that's 2 strong use-cases: hit testing and changing the layout
23:10:33 <slightlyoff> plinss: we need to enable participating in the layout process
23:10:41 <slightlyoff> plinss: that'll let you polyfill new layout behaviors
23:11:13 <slightlyoff> Domenic: does that mean that it's going to be "position: managed by worker"?
23:11:23 <slightlyoff> plinss: you'd probably change it's display type
23:11:28 <slightlyoff> (discusion of D3)
23:12:19 <slightlyoff> plinss: you might use the worker element and prime it with information about the layout
23:12:26 <slightlyoff> plinss: people have been asking for this stuff for years
23:12:41 <slightlyoff> plinss: CSS OM has been........(inaudible)
23:13:10 <slightlyoff> wycats: we talked with Tab a few weeks ago, but what people are asking for isn't perhaps what peopel want
23:13:40 <slightlyoff> wycats: we're making progress here...what's the next incremental step we can take?
23:13:53 <slightlyoff> wycats: we want getBoxQuads() (in an async way)
23:14:27 <slightlyoff> annevk: getBoxQuads() does different things from the layout tree. The transforms we have in CSS today don't affect the layout tree but does affect the eventual rendering
23:14:48 <Zakim> Zakim has left #tagmem
23:14:52 <slightlyoff> (discussion of ambiguity)
23:15:05 <Zakim> Zakim has joined #tagmem
23:16:49 <slightlyoff> Domenic: it seems we need the 2 large base objects (layout and render)
23:17:03 <slightlyoff> annevk: is the architecture in Servo that the layout tree is in a separate thread?
23:17:07 <slightlyoff> dherman: yes
23:18:15 <slightlyoff> dka: is there some sort of statement we can ship over to the CSS WG?
23:18:26 <slightlyoff> wycats: it seems like we'd like to do a SW-like thing for rendering?
23:18:36 <slightlyoff> dka: I also heard some requests for the CSS WG
23:18:49 <slightlyoff> plinss: yes, but we're missing the larger architectural model for the CSS WG to do the work in
23:19:15 <slightlyoff> plinss: someone needs to layout out how a multi-threaded browser rendering engine works
23:20:48 <slightlyoff> plinss: when we have that, it'll help the CSS WG Move forward...the WG probably isn't the right place to define how the modern web's architecture shoudl be defined
23:20:58 <slightlyoff> dka: call? what sort of group?
23:21:10 <slightlyoff> slightlyoff: we need some of the right people in the room, layout hackers
23:21:21 <slightlyoff> (note that some of these people will be at the EW summit)
23:21:31 <slightlyoff> plinss: where do we host this work in the W3C?
23:21:37 <slightlyoff> TAG? etc.
23:23:50 <slightlyoff> BREAK
23:27:24 <annevk> dka: https://pbs.twimg.com/media/BkJTj5KCMAAmCSJ.png
23:34:03 <slightlyoff> back
23:36:52 <slightlyoff> Topic: custom everything
23:37:00 <slightlyoff> plinss: custom properties are coming
23:37:07 <slightlyoff> slightlyoff: can you explain what you mean by that?
23:37:51 <slightlyoff> plinss: people have been asking for variables forever, and we've been pushing back on that...instead, what we're doing is a system where an author can define a property, give it a value, and defer to the value of anotherp roperty as that other property
23:38:00 <slightlyoff> s/other/first/
23:38:25 <slightlyoff> Domenic: so there's 2 parts, the ability to not throw properties away, and (missed it)
23:38:39 <slightlyoff> plinss: you can only refer to custom properties
23:39:33 <slightlyoff> plinss: you can't refer, e.g., to another element's width
23:39:39 <slightlyoff> (discussion of cycle breaking)
23:40:18 <slightlyoff> (discussion of where initializers come from)
23:40:26 <slightlyoff> slightlyoff: what's the interface to JS?
23:40:30 <slightlyoff> plinss: part of the CSS OM
23:40:40 <slightlyoff> Domenic: it uses a map class thing
23:41:39 <slightlyoff> wycats: is it global?
23:41:40 <slightlyoff> yes
23:41:55 <slightlyoff> Domenic: that's custom properties...pretty cool...next, custom pseudo-classes
23:42:08 <slightlyoff> plinss: pseudo classes reflect state
23:42:18 <slightlyoff> Domenic: why is a custom pseudo class different than a custom data attribute?
23:42:34 <slightlyoff> plinss: you need to be able to determine if a pseudo-class matches or not, and this needs to be fast
23:42:57 <slightlyoff> (some work has been done)
23:43:14 <Domenic> http://dev.w3.org/csswg/css-variables/
23:43:37 <Domenic> "The CSSVariablesMap interface was removed"
23:44:27 <Domenic> http://tabatkins.github.io/specs/css-aliases/
23:45:16 <slightlyoff> wycats: I'd like to talk about custom pseudo-elements.
23:45:46 <slightlyoff> wycats: right now, the way you're supposed to style custom Shadow DOM is to put the styles inside the SW itself, or you can use the ex-cat-hat things
23:46:05 <slightlyoff> (pseudo-elements)
23:46:16 <slightlyoff> wycats: and you can theme custom elements this way
23:46:18 <Domenic> Ex-cat-hat live here: http://drafts.csswg.org/css-scoping/
23:46:25 <slightlyoff> wycats: but it doesn't work when you want real information hiding
23:46:33 <slightlyoff> thanks, Domenic
23:46:48 <Domenic> http://drafts.csswg.org/css-scoping/#shadow-pseudoelement
23:46:53 <slightlyoff> wycats: as Tab pointed out, you want to let these things relate to each other
23:47:49 <slightlyoff> wycats: as someone who makes custom elements, putting components in shadow DOM today is pretty good...you can get some style isolation
23:48:36 <slightlyoff> wycats: ember would like to have a flag that lets you build elements this way...but there's a lot more work that goes into an information-hiding world than the loose world
23:49:02 <slightlyoff> wycats: I'm not against the cat/hat idea, but I'd like to have pseudo-elements because I want to provide the high-fidelity path
23:49:12 <slightlyoff> wycats: and I can't do that today becuase I don't have them
23:49:28 <slightlyoff> Domenic: you want to lock down everything but the pseudo elements
23:49:33 <slightlyoff> plinss: that's orthoginal
23:50:09 <slightlyoff> slightlyoff: think of the custom pseudos as the IDL vs. the vtable walking of cat/hat
23:50:37 <slightlyoff> Domenic: you could imagine a sort of community contract
23:50:44 <slightlyoff> slightlyoff: I expect this to happen in the short run
23:51:14 <slightlyoff> wycats: I think jsut using the selectors/custom elements is going to suck...very few API signaling mechanisms
23:51:49 <slightlyoff> (discussion of how to lock thigns down vs. advertise good API)
23:52:07 <slightlyoff> (CSS wg has concerns)
23:52:54 <slightlyoff> plinss: cat/hat is a combinator that lets you select inside the SW, and what we have now is something that lets you name the root of the SD as a pseudo-element (::shadow)
23:52:59 <Domenic> 	x-foo::shadow > span
23:53:29 <slightlyoff> plinss: my proposal was to suggest that instead of regular selectors, expose all items inside of it as pseudo elements and let authors name them
23:53:42 <slightlyoff> wycats: I want something like that
23:54:32 <slightlyoff> Domenic: right now, it's > # to select something with an ID, but "::shadow thing" would select the thing by ID?
23:54:51 <slightlyoff> plinss: you could still use the IDs and classes in my proposal, but you'd refer to the node as a pseudo-element
23:55:07 <Domenic> Clarifying: "x-foo::shadow #foo" vs. "x-foo::shadow::foo"... is this substantially better?
23:55:16 <slightlyoff> plinss: if your element is nothing but <p>'s and <div>'s, you'd say ::p and ::div to get at them
23:55:30 <slightlyoff> plinss: if you want to give them names, you'd be able to have ::foo
23:55:42 <slightlyoff> plinss: and then you'd be able to have a flag for hiding or not
23:56:35 <slightlyoff> slightlyoff: not sure "::p" is a huge win
23:56:47 <slightlyoff> plinss: you wouldn't need the ::shadow prefix in my proposal
23:57:08 <dka> rrsagent, make logs public
23:57:13 <slightlyoff> slightlyoff: doesn't this prevent you from defining new pseudo-elements in the future?
23:57:15 <slightlyoff> plinss: no
23:57:18 <dka> rrsagent, draft minutes
23:57:18 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/01-tagmem-minutes.html dka
23:58:14 <Domenic> It would actually be x-foo::--foo
23:58:47 <slightlyoff> (discussion of prefixing, namespaces, and whatever the 3rd hard problem in CS is)
23:59:24 <slightlyoff> plinss: my proposal has been that there be no anonymous boxes in CSS, but rather that they all have pseudo-element names
23:59:51 <slightlyoff> plinss: I'd like there to be a custom set of boxes applied to elements