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