See also:
Agenda
Raw Minutes taken on OkSoClap Etherpad
IRC log
Agenda: https://www.w3.org/wiki/TAG/Planning/2014-07-F2F#Proposed_Topics
SK: There is a new edition of web animations; they basically incorporated everything we said. So we should do another round.
AR: Are there any other issues you think we should work on, or just wanting to tie things off?
SK: Not sure yet; will go through and let us know.
AR: we should talk to them, say we noticed what you did, that's awesome, how can we help in the future.
DA: no need to invite onto a call unless they think it'd be useful.
DD: in particular did they fix the issue where play() does not actually play the animation?
SK: not sure... just saw it yesterday. But they fixed several other things.
ACTION: SK to reach out to web animations editors to start the conversation [ACTION-872]
DA: "Hey, we saw you incorporated our feedback; that's great; thanks for listening. If you'd like to have any further discussions, have your people call our people ;)"
YK: we are trying to get ES6 done. There is pretty much a moritarium on new features in the "ES6 branch"---we are talking about cutting things, not adding them. We have agreed to switch to a new process for ES7 (feature at a time evolution; snapshots). There are features that are already working this way, including some that have gotten fairly stable, but there's confusion because the legacy ES6 process is still ongoing. Practically, the good news is that any feature not stuck in the ES6 morass has been unchanged.
YK: I think that's the overall shape of it. There have been tweaks to some things, and thanks to the timing, that creates a lot of anxiety.
YK: also, the schedule slipped 'till 2015, but we're doing a poor job of messaging that and that we should decouple ES6 features from the ES6 process. Many features should move to stage 3 or 4 in the new process.
DD: whoa. That means that Modules would get cut.
YK: transpilers count. We have implementations. Even for the Loaders API.
DD: they don't have high fidelity and that some implementers of loaders are saying that there are holes in the spec.
YK: you should raise that. But Symbol has implementation issues, e.g., and it's Stage 4 territory.
<discussion>
DD: I think Modules are at a disadvantage.
DD: LOOK! DASHBOARD!
DH: If there are issues coming out of impls that I don't know about that, that's a problem. What don't I know?
DD: lots of extensions in jspm. Seems to require them. JSPM doesn't work without the extensions
DH: same can be said of internal impl hooks. Doesn't actually mean the design has holes. I'll reach out.
DD: https://github.com/tc39/ecma262
YK: the meta-point is that we want to backport the process as far as possible.
DH: we need to work with implementers to unblock people.
AR: different question: what's your view of the impact of schdule change?
DA: what's the schedule change?
DH: you only get to do an ECMA spec once ever 6 months as the GA only meets that often. ES6 is largely written but there's a long list of missing details and edits that need to be incorporated. There are some bits missing in the Modules section. The biggest pieces are done and there's editorial work to do. We planned on a GA vote in Dec of this year but w decided to push that out 6 months to the next GA vote in June.
DH: to YK's point, this isn't about delaying the design decisions, it's just about finalizing the editorial work about decisions we've already taken. We don't want this to mean that things can be re-litigated or the rest of the world to think that things are unstable. There are questions about "how baked is this?" and it's causing some implementers to hold off. E.g., browsers feel they can't start implementing modules until the browser loader is specified (which is separate from ECMAScript).
YK: to clarify, TC39 has not defined how modules get loaded (e.g. in browser vs. Node) so we have specified hooks instead. We need to help getting that ready.
DD: The schedule change has no impact on how other specs are referencing the spec. People are referencing the latest version for all sorts of things: HTML event loop integration; promises; service worker; ...
DH: in general people are referencing the parts that they know are done, e.g. promises, but people---including implementers---don't know relative stability for all features
DD: each champion will do the early pre-stage 3/4 implementation work
DH: good point. Also transpilers are very easy to experiment with and change.
YK: browser vendors do care about spec stability. The separate stability chart would be helpful.
<Discussion of how to give stability signals when modules are still having their details worked out>
DH: modules are too heavily politicized
<Discussion of horse_js thread>
<Discussion of cross-browser progress and Alex's tactics>
YK: I think about a year is the fastest we can get for true cross-browser consensus
AR: Then we are boned.
YK: If you think shipping something in Chrome results in things going faster, you are wrong.
AR: that is a caricature
AR: the whole controversy was about where to bring things up. TC39 is not the right place to bring certain things up; they areTC focused on the coherence of the JavaScript spec, instead of on web architecture. <sarcasm>horse_js quoted me out of context, which is hard to do on Twitter.</sarcasm>
DH: I think this is a bidirectional problem. Part of my reason for joining TAG is that the division between the ES and the web side of the world is problematic. TC39 doesn't pay enough attention to the integration questions. But TC39 is very good at overall design cohesion, and the browser side does not do very well there. I worry about the massive amounts of technical debt on the web platform, and I like the extensible web approach to fixing that. Unfortunately sometimes cohesion comes into conflict with scheduling.
DD: Interjection with more TC39 update---test262 is now open for contributions much more easily! It is getting community contributions and being actively worked on and moved forward.
DA: what can we do actionably to address DH's points?
DH: when there are platform things that need things in the language, we can provide some schedule pressure to TC39. E.g. letting web implementers use the TAG as a communication channel to TC39.
AR: in particular the secure workers example...
<Discussion of whether workers should be web- or language-level>
DH: that kind of work can proceed outside of TC39 because ES is not ready for it.
DH: what is a secure worker?
AR: we have a conceptual issue around things like web crypto. They must be outside the JS memory space to avoid observability, including things like timing attacks. They often include operations that must be performed inside specialized hardware or similar. What this means practically is that it's hard to build web platform features on top of these operations because they live externally; they are not conceptually part of the web platform so you have no ability to compsose them. You cannot build privileged crypto in the web platform today: there is no way to have code run that can be verified or tamper-proof or given keys for authentication or similar.
DH: so one way of saying this is "imagine if web crypto was self hosted?"
YK: and this would work for a DRM system? (Perhaps not one fully satisfactory to content owners, but conceptually at least?)
AR: yes.
DH: <relating this to the threat model... is the user considered hostile?>
AR: yes the user is considered hostile. One of these things would be un-debuggable under any circumstances, unless you had the signing key for your origin.
PLH: Back from IETF in Toronto yesterday.
PLH: one of my goals for this year is to ship HTML5 this year. The Director wants to have a stable reference to URL. We have been trying to find a solution to that. The IETF IRI working group died in 2012; they failed to maintain the IRI specification. Anne has been doing lots of useful work on this front; the main driver is that the way URLs are handled in web browsers is a bit of a mess. Human input is involved, versus what the network layer is willing to accept. Anne has been doing fantastic work on that. On the one hand we have an unmaintained spec in the IETF with a bunch of unresolved issues; on the other hand we have a WHATWG spec which address the problem from the point of view of the web browsers. Plus on top of that there is an incompatibility between the URL specification and the RFC 3986 (the URI specification used by HTTP).
AR: can you outline the incompatibility?
PLH: no, I cannot. They are not well documented. Nobody is clear on what they are. There is simply a suspicion of incompatibilities. From the IETF point of view they have plenty of protocols using the RFC 3986/3987. They do not want to let the web diverge in this way.
DD: one thing I heard was potentially incompatibility was file URLs.
PLH: also data: URLs, which have implementation incompatibilities between browsers. Also percent encoding. Also whitespace handling. And of course there are several locations in the stack where URLs show up, so it's unclear which each refers to.
TBL: different goals: what is in the HTTP headers; what is in the .href attribute; what is typed by the user in a URL bar. People are dragged in different directions to satisfy these three cases.
PLH: we have several issues. We want a snapshot that we can refer to from the HTML5 recommendation, knowing that it is scheduled to go to REC very soon.
<DIscussion of whether it is allowable for RECs to reference living standards.>
PLH: another issue: how do we see URLs and IRI moving forward in the future? The IETF specs are broken and they acknowledge they do not have the resources to fix them.
https://www.w3.org/International/wiki/IRIStatus
PLH: another issue is the test suites. We don't plan to deprecate the IETF specs because so many things use them. But we want to commit to a v.next of the URL specification that would indeed replace them. Either changing 3986 or changing the browsers.
PLH: everyone was on-board with the plan as long as there was a commitment to work on vNext. We won't have a commitment to work on v1.
PLH: we want to work with Anne in this case, similar to the DOM. We don't want to work against him. We want to avoid as much as possible of a fork. I also want to work on what problems can be fixed with regard to browsers vs. 3986, and with regard to i18n.
DA: practically speaking, the webapps working group is rechartering with URL in their charter, with the requirement that it publish under CC-BY. Robin has helped to set up a repo.
DD: want to make sure implementers and developers are directed to the latest upstream WHATWG version.
DA: there's also the issue of whether everything in Anne's document is implemented or not, and is therefore testable or not.
PLH: yes. There were similar things in the DOM spec.
DA: for vNext we should make it a collaborative process with the WHATWG version.
TBL: maybe GitHub can help. Remember the reason why this is not one document is the licensing religion wars. If we can build a GitHub system that allows us to bypass the multiple document problems, that would be helpful.
DA: the way that we're setting things up for URL is an attempt to get work done despite agreeing to disagree. Anne doesn't agree with this approach, and I don't agree with his statements. We are still on speaking terms, so ... seems OK?
AR: the reason the W3C exists is to provide a good open playing field with well-understood rules that everyone can get by with. To the extent that the WHATWG doesn't give those, the W3C has a place.
PLH: this is not a new debate. We have never been able to give an answer to what the audience of a spec document is, and never will be.
AR: given that the W3C isn't going anywhere, how can we reduce the delta between goals.
<Discussion of how well real-world URL parsers work. Do they?>
DA: current spec doesn't have much explanatory text. Ideally needs some additional intro, more actual terminology in the terminology section, etc... Work in WebApps wg can be a catalyst for getting this feedback (and hopefully channeling back through the WhatWG).
YK: Anne's style specs with large switch-based algorithms is extensibility-hostile.
DH: feels like that is a step along the way toward figuring out what's actually going on.
TBL: I like specs with a grammar.
PLH/DD: grammars don't usually work for edge cases or error cases.
TBL: in an ideal world we could have a grammar.
PLH: even though it's in webapps, I think the TAG should care about URL quite a lot. Please take good care of it.
DA: the only thing TAG members agree on is how important the URL is.
DA: any other items from the IETF to share?
PLH: I was talking with Larry Masinter; he's planning to revive multipart/form-data. It would be good if the TAG could look into it and give feedback. Also URI registration: draft, http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-01, slides from yesterday http://tools.ietf.org/agenda/90/slides/slides-90-appsawg-1.pdf
DA: any news on HTTP2?
PLH: nothing yesterday; maybe today but I cannot be in two places at once. One issue that did come up was with regard to proxies. Some implementations of HTTP2 will require HTTPS. This could be problematic for performance; 4x RTTs.
AR: RTTs are exaggerated because of the TLS handshake.
PLH: they were reminded that TLS was designed for end-to-end encryption. But the rise of TLS on the web (which has doubled in the last twelve months) has a big impact on the intermediaries.
<Vague discussion of proxies messing things up vs. being useful.>
YW: the creation of SPDY was for Google use cases, e.g. TLS in order to avoid bad proxies. But for HTTP2 we might want to use TLS to avoid being snooped on. It's probably not going to be in this version, but it will be in the next version.
RB: I think the way that we have had to manage HTML so far was necessary to ship, but we should rethink going forward. I know there has been acrimonious debate about modularization before. I'm hoping to propose something less controversial. As part of this change I think we need to make HTML into a large number of small specs that would be handled by a large number of people. And at the same time it would be important to switch the license to a properly open spec.
DA: do you think this would also involve moving to a different community engagement model, a la Discourse?
RB: I do think ideally it would be part of a general reform in how we do standards, but I don't want to make it depend on other such changes. I think we are doing a relatively bad job benefiting from a community that has a wealth of expertise. By getting more editors and more input we'd be in a better place.
DH: Brian Kardell, Yehuda, and I have been having conversations about what processes we want for a community Discourse instance (on specifiction.org). There are challenges of how to deal with the firehose problem. es-discuss is an anti-example. It is high traffic but with a small and self-selected audience, so the people whose job it is to keep up with the standards don't have time to keep up with it.
AR: that's the charitable view.
DH: how can we build processes that allow us to sort through the noise and find the signal? We've talked about e.g. having two channels for a given topic, one that is for wider discussion and one that is more administered or mediated. Talked about building relationships with more trusted community members that can do the job of effective curation. This is important for building effective communities. It both helps spread the workload and helps grow standards people by creating a path for them to go from unrecognized member of the community to recognized member and possibly ultimately to a member of the standards process. You could look at Domenic's path for example; we could actually try to foster that. My larger point is that we need good processes and people management more so than technological issues.
RB: I agree. In terms of focusing discussion I think splitting the spec could help: then not everyone has to talk to everyone else about all of HTML. For example we could use Discourse for the general community stuff, but perhaps move more focused discussion to GitHub issues.
DA: Robin, how do you see mapping this vision onto the existing working group/W3C/IPR structure?
RB: if we do move in this direction, I think the split between working groups will become more artificial (than it is already). I can't say I have a good solution on the, e.g., three-year horizon. For the short term we can split the HTML specification within the HTML working group.
PLH: I look at Robin's proposal from the perspective that we have webapps, html, and css, all acting in different ways. I am afraid HTML would end up where CSS is now, where you can't tell anyone what CSS is.
DD: how would this be different from how HTML is today?
YK: I think it is a messaging issue. I.e. CSS is stuck in between features and mega-spec, so you have to find which abstract mini-spec your feature is in.
DD: To second Yehuda, breaking down by feature is really important.
AR: but a global coordination function, e.g. ES's yearly release process, is important
RB: we should not be scared of splitting specs into tiny little specs. If we do that though, we need a big index that points to absolutely everything. Curating that is work, but if we do things right in splitting things, it can be done. I agree that CSS is an experiment in splitting things up---I think we need to learn from it.
DD: <picture> element integration into HTML is a success story.
RB: yeah, the details got a little messy, but from a high-level, yes. I definitely kept RICG in mind when coming up with this.
DA: So ... how can we help?
RB: the best way to help is to just get the work done
AR: I do not necessarily think this is a good idea
DH: My biggest fear with modularizing is that it can decrease coherence and cohesion. The more we parallelize and make it easy to parallelize, the easier it becomes to lose coherence.
DA: it does seem like that aspect, as well as how it splits, is clearly something the TAG should be concerned with.
RB: I agree that's a concern. My thoughts on how to mitigate that is to get more developers and people involved, which will provide more feedback earlier in process. Developers are good at finding inconsistencies. Also we can use a very simple branching convention, such that you can only merge things to master once things have tests and those tests pass in real implementations.
DH: that's all well and good. But the part that is missing from the entire space, and is also missing today (so maybe modularizing won't impact, but it won't make it better) is that the design process is an iterative process which moves between large and small picture. But we don't have any flows in place to make those things happen.
YK: part of the problem is that the TAG doesn't have direct authority.
DA: but our feedback is definitely incorporated.
YK: but if we want to have a formal hermeneutic circle process, and we want the TAG to be part of that, we need to say that. We are currently not that.
DA: wouldn't this involve a charter change?
RB: I don't think it would need one.
DA: I'm just thinking of how we can bolster the formal relationship with the TAG.
RB: we can just make that part of the policy.
DD: I think Hixie does a good job maintaining cohesion within HTML itself, modulo legacy constraints.
AR/YK/PLH: disagree.
YK/AR: he has been good at archaeology, but not cohesion.
RB: gotta go
AR: I would take away from this that not everyone is behind this idea and there is definitely some concern.
[lunch]
[Brian Kardell and Philippe Le Hegaret joining us for the afternoon session]
DD: Plan: (a) what's wrong, (b) architectural issues, trying to find realistic starting point
YK: Heard lots of "what's wrong", but just few "what's OK"
AR: There lots of questions, mostly about performance, since it's easier to change a system without any API. These days are in past, now all systems have APIs
AR: You may start with something semantically nice and reasonable from performance point of view
AR: CSS have no APIs for events, render trees, hit testing, etc.
AR: CSS variables, where are they?
<PL&AR: discussion on media queries>
AR: CSS is high priority thing to work on, to explain how it works
DD: Render trees and hit testing are most important issues
AR: It's diffcult to talk about that because implementations differ (e.g. in Safari)
<AR explains threads & hit testing architecture>
AR: I think there is a lot of uniformity in render trees
DD: Many things are not stored, like input cursor position, is the select box open, etc. If you re-render those will be blown away.
<YK, AR, DD explain React program model>
<AR, DD on fingerprinting>
[question is: should the TAG support efforts to limit fingerprinting or should we declare fingerprinting a "lost cause" - contraversial either way]
AR: There is no API to measure dimensions, there is no way to place layout in desirable manner
YK: React does not operate in terms of box trees, it's just html
DD: React is not a clear way to say "people want operate render boxes". Famo.us is better example of this
<AR on how designers work>
YK: There things which are extremely needed, like button looks like exactly, and you have a choice: allow browser to render such elements, or impelement them in desirable manner completely
<example with scrolls>
AR: The problem is relationship between DOM and render trees which are not the same (hidden elements, pseudo-elements, etc)
DH: If you are capable of both manipulating DOM and render trees, you have a problem with that. We in Servo don't want to have in fact WebKit standardized
<AR on different threads which JS could manipulate>
PL: We had such a conversation in CSS WG and we had a pushback from MS as they have no trees. Trident cannot do that
DH: But Servo isn't established setup, we're experimenting
PL: I agree, but I still think we could take a render trees as an abstraction of DOM rendering. There is conflation between DOM API and box trees.
PL: We may expose box trees as subclassable objects
TBL: Is it worth to ask people who do not have box trees to explain their architecture?
DH: Agreed, Servo has no box trees
AR: If you do not want your architecture to be affected by standards - you need to participate in standards activity
PLH: It's not a new question. For example, people want to know real frame rate of my animation, but in render trees it's impossible since that's not DOM.
PLH: We can give you two frame rates: DOM updates and render updates, but how to treat them?
AR: Imagine, there is a separate thread. You could potentially have asynchronous API.
PL: At least you have to compute the structure of entire document
DD: There are two ways. (1) everything is asynchronous, (b) have a worker
<thoughts on threads>
BK: There is no concept of custom functions, superclasses now. IMHO that's a good way to build features
YK: For me the biggest problem is an absense of access to OS-provided elements
DD: Box tree API could provide a box tree "there is OS element, lots of magic inside"
YK: But I want just to borrow, for example, native scroll, native focus behavior, etc
YK: To allow users to do more custom elements, you have to expose native elements
PL: Just like shadow DOM, there could be Shadow Box Tree
YK: It's still a magic
PL: on scrolls: imageine you have boxes, and you can borrow that os-powered box to apply to your element
YK: Could it be done -- to expose scroll behavior? It's extremely magical and complicated
YK: It's very diffcult to emulate iOS scroll for example
YK: I want an API like: make me a scrollable area here. Trigger scroll events to that canvas
<dicsussion on how to expose magic>
DD: With boxes you'll have a better foundation to say: that's scrollable box, for example
DD: That API could tell you where are boxes for each element of the text, it's super-valuable
<dicsussion on implementers will>
DH: Implementors don't like exposing low-levels things, better to say "we have nice API explaining sematics"
<story from David>
BK: What are you aware of?
YK: That was Ruby way, to expose implementations and then find it was bad implementation
DD: Our purpose is to expose hit-testing
AR: Disagree
DD: Do you propose an idea like "tell me waht happens if I render something"
AR: Yes, it's natural to mesaure elements, for example.
<AR explains dom-tree and render-tree relations>
YK: Current CSS tools are very bad in building app, especially in putting third-party content
<YK explains a problem with Cocoa and intrinsic sizes>
AR: pluggable media queries, line layout/line breaking: what's the API for figuring out text wrapping and sizing?
YK: having to render into the document to figure out how big something is.
YK: Cocoa has an API for line layout.
AR: watch result if CSS parsing, no laguage for CSS-OM
AR: better exposing of custom properties
<discussion on new CSS OM>
PL: CSS rules apply to boxes, not to DOM elements
PL: Style tree is independent from DOM tree
AR: We talked with Tab about exposing genereated boxes
PL: By matching rules yout create a Style tree, which contains extra elements
AR: list style bullets, etc
PL: There is one dom node and probably several boxes
AR: You can make a dictionaty of variables
PL: Style reasolutions happen frequently and have to be very fast
<asynchronous vs workers and passing references once more>
PL: We talked with CSS WG about exposing box tree, it's usable to have them involved
PL: Nobody (except for me) champions this api in CSS WG. We should form a task force and start work
DD: Maybe find use-cases developers really want?
PL: We should say getBoxQuads is right, be we need to go farther
DD: Probably define a part of box tree?
PL: Box tree could have another structure than dom tree
<PL explains troubles with elements positions>
PL: getBoxQuads allows you quering box tree attributes
DD: So, box trees, media queries, selectors
PL: Selector core is very highly optimized thing
<AR about YK's idea of sync points which we do not have>
<AR, PL explain information flow>
<What do do next?>
<AR still wants an API for line breaks, etc>
PL: Do you mean all potential breaks or what will really happen?
AR: font metrics, first-pass estimation of breaks, and high-resolution break/placement.
DKA: Could we summarize all that, what APIs to propose?
ACTION: "next steps for CSS" proposal, small group work done asap
PL: Expose CSS parser, everybody has it
ACTION: form a box tree reification task force within CSSWG, with TAG representation
AR: Possibily make it a recurring agenda item?
[meta-discussion on how to organize initiatives, task forces, etc...]
DKA: frustrated with weekly calls, no people. Let's make us more effective
YK, DD: This information [status updates] could be sent by e-mail
<discussion on whether we need calls>
DH: We need to organize agenda topics better
<DKA's telling about good old times>
<TimBL doesn't like doodles>
DKA: IRC chats instead of calls? Two optional sessions every week. Stand-up emails, IRC sessions on Tuesday and Thursday
<decided:
Email status updates on Wednesday
Two IRC calls: 8 a.m. (15:00/16:00 UTC) Pacific on Tuesday; 10 a.m. (17:00/18:00 UTC) on Thursday
ad hoc calls>
BK: There are lots of things which are still not extended.
AR: We spent 4 years begging.
BK: One good thing is Polymer's platform.js
YK: Does it really work, it requires lots of modern stuff? Probably better break features which do not work in older browser
DD: There are interesting polyfills, like Pointer events
YK: Many platforms support older browsers, old IE is 20 per cent
[Do we need an "Extensible Web Report Card"?]
BK: Now Polymer has many things which are not implemented by all major browsers. Basically it's a competition of new things.
YK: We have to feature-detect polyfills, whether they're good or not
BK: We need to involve community, write more tests
DD: People are enthusiastic to write tests
<DD explains tests idea>
DD: Test coverage of many things is bad. Making developers aware thay can contribute is a big deal
DH: Do you now how to do that?
ACTION: DD to think harder and give a plan outline for involving developers into tests/polyfills more. E.g. encourage spec editors to explicitly call out polyfillable/testable sections, and how to bring developers into those conversations. [ACTION-873]
<discussion somehow returned to CSS>
YK: Situation goes even worse, we have to write html5 parsers
DKA: Let's return to "Report Card" idea
<DD talks about an idea of "Extensible Web Dashboard">
DKA: We really should have such a document.
DD: This will show our progress
YK: There is in fact a good story about Web Components, which are decoupled from other stuff, but people still over-react
<Discussion on Web Components, Custom Elements and their pros and cons>
DKA: Do it as a github page?
BK: Sort of "what we accoplished" and "what we have to do" and how it fits the larger thing
<BK tries to recall who helped him to make such a list>
DD: What should we put there? Our success stories? What things we want to encourage? Things we're working actively on?
DKA: Demonstrate some continuing energy
BK: The idea of Manifesto is "we want to reach this goals", and we can't do that without things like CSS archeology, etc
BK: Lots of engineers never saw a single spec. We should make efforts
DKA: My experience is that you could gather developers who are interested in standards, and some will contribute
BK: We have the structure of colleges and businesses, it should be possible to have a "spec" meetups. Use meetup structure to critique specs. Developers see things implemented in browser several years after they were really implemented.
DKA: The idea of community groups was to do that. [nb: not saying there is nothing to do - agree there is lots more to do]
<DD explains action he has taken>
BK: We have to organise communication to productive channels and filter noisy channels
DKA: What are concrete actions?
DD: A list of things we want to put + README (what are our goals)
DKA: https://github.com/w3ctag/extensible-web-report-card
<dicsussion on Specifiction and its current state>
<a minute of good humour>
DKA: Should we start a topic on Specifiction?
AR: caniextend, like caniuse
<TimBL asks about Packaging on the Specifiction>
http://dev.w3.org/fxtf/geometry/
[guests: Dirk Schulze, Rik Cabanier, Robert O'Callahan]
DD: Sorry for the manner of organizing review, thanks for working with me. I'd like to hear your opinion on making more advanced things with CSS
DD: This in interesting spec, it defines lots of new interfaces, that's the general plan?
RikC: The goal is to add DOM metrics, make transorms more acceptable and approach to SVG
DS: SVG has long history. Spec (SVG DOM) is very hard to understand and implement. Now we're adding interfaces to create objects directly and to parse SVG
DS: Object model is very basic things, and we're trying to expose more data, especially with transforms. We work on geometryAPI which provides more information, what actually happens. It introduce basic interfaces like Point, etc
DD: Were you successful in that?
DS: We introduced some new things.
RC: Some things were not constructible, now they are available
<YK asks about array-like objects>
https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGAnimatedLengthList
DS: We can't improve them now, we're discussing that
<discussion on SVG oddities like such lists>
DD: SVG 2 to fix that
DD: You said these primitives to be used in other APIs. Did you mean render trees?
DS: No, just basic CSS models
DD: Box Quads?
RikC: Box Quads don't expose anything new while exposing a render tree requires defining lots of stuff, pretty fundamental things. We could expose them via dom tree, but it's extremely hard to maintain. We don't want to constrain implementations.
DD: Render tree could be the same as other things defined in css spec
RoC: In css spec you have blocks. We talked how to change that, but every api exposing boxes [?]
DS: It will be good to discuss render tree and use-cases. Do you have any additional thoughts and ideas?
DD: Anything more we could help aprt of constructors and other microthings?
DS: Thank you very much, we'll use your help
<dicsussion on some techical detail scribe isn't aware of>
<discussion on DOMRect, immutable prototype properties and subclassing>
[quests off]
https://yadi.sk/i/Ig7CxcuZX9UN4 (Copied to W3C space: Copyright.pdf<)/p>
relevant to Sergey's slides, internet-connected everything: http://www.technologyreview.com/news/528121/a-contraceptive-implant-with-remote-control/
relevant to Sergey's slides, what w3c can do, passwords, encryption, etc... : http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/Overview.html
BK: We should note community groups spinning up which are relevant to these ideas...
AR: Auto-update is a key [element | thing you need to have].
DH: "Internet of Evergreen Things"
DH: can standards groups reach out to industries
DA: w3c has run a payments workshop which involved many banks and financial institutuons - an attempt to do this [see: http://www.w3.org/2013/10/payments/].