polyglot

<wycats_> http://wiki.whatwg.org/wiki/HTML_vs._XHTML

<noah> Link to XML/HTML Task force report: http://www.w3.org/2010/html-xml/snapshot/

<slightlyoff> yeah, I don't understand how namespace'd XML docs are relevant

<plinss> http://www.w3.org/2001/tag/2013/03/18-agenda

<wycats_> I want to discuss the list of polyglot use cases that are not satisfied by XHTML

<wycats_> you can use IE if you want XML islands ;)

<wycats_> "Support for XML data islands has been removed in Internet Explorer 10 standards and quirks modes for improved interoperability and compliance with HTML5"

<JeniT> the script element is the thing to use

<slightlyoff> we added this for <template>, BTW

<JeniT> can you use arbitrary XML in template?

<slightlyoff> it's in the spec, but not the implementations

<wycats_> you could theoretically have <template type="application/xml">

<wycats_> but the window on that is rapidly closing

<slightlyoff> many implementations don't stop on first error

<slightlyoff> see: RSS pipelines at scale

<slightlyoff> also XAML processing

Noah: discussion about error handling around xhtml, xml5

Anne: brwoser vendors lost interest (in xml5)

Jeni: one case is where you don't control the mime type on the server

wycats: not sure this is a high value, the fact that toolchains don't have that is an indication

<slightlyoff> well, they have built those tools: lots of languages have both XML and HTML parsers; just run it through both and look for exceptions ;-)

<slightlyoff> xmllint + HTML::Lint

wycats: you don't need waiting for a spec to write a tool to help for that use case

anne: your xml toolchain can have html endpoints (input and/or output)

wycats: there might be confusion on when to use html, xml and polyglot documents

Noah: the relationship between polyglot and xhtml is a subset/superset one

wycats: I don't want to have people saying "to be safe, use polyglot"

<JeniT> the other example that I was going to raise was the E4H example

<annevk> JeniT, we already know it's not likely to happen, seems ratholing

<JeniT> but in general: defining a parser for a simple subset of XHTML is much much easier than using a full HTML parser

<annevk> JeniT: you want a third parser?!

<annevk> JeniT: that is so crazy

<annevk> JeniT: parsers are not rocket science

<wycats_> E4H is a crazy reason to want polyglot

<annevk> that too

<wycats_> people would want @<img src='foo'><p>hello</p> to work!

<wycats_> "just use polyglot" is ridiculous

<wycats_> for anything like E4H

Alex: I'll look at the wording on the status section and redraft it.

<noah> ACTION: Alex to redraft proposed "status" section that TAG is suggesting for Polyglot [recorded in http://www.w3.org/2013/03/20-tagmem-minutes.html#action01]

<trackbot> Created ACTION-791 - Redraft proposed "status" section that TAG is suggesting for Polyglot [on Alex Russell - due 2013-03-27].

<JeniT> annevk, I'm merely using the E4H requirement as an existence proof that such a parser might sometimes want to do that

<annevk> JeniT: "defining a parser for a simple subset of XHTML" is still crazy

Layering

wycats drafting on the white board^Wscreen

Jeni: how it would help people developing platform features?

wycats: by providing guidance

Anne: should we restrict that to markup APIs?

<slightlyoff> I think it's important for us to say that markup and APIs need a concrete relationship

<slightlyoff> so declarative and imperative forms need a relationship, as do high and low-level APIs

<annevk> What I meant to say is if we should be explicit that this includes markup as well as APIs.

<slightlyoff> annevk: I agree with that

<slightlyoff> annevk: and it's all about creating connections between the layers

<slightlyoff> I think it's important for us to identify that people should be trying to create connections between layers

<slightlyoff> not pre-suppose a fixed # of layers

<slightlyoff> (1, N, or somewhere inbetween)

anne: there are many layers in XHR, as redirection, decoding and getting content are different layers

ex, redirects are currently not handled as we don't have the right API

<slightlyoff> JeniT: I don't think our problem there is as large -- "progressive enhancement" is the received wisdom amongst FE-engs.

<JeniT> agreed

<JeniT> but I wonder if there are patterns there that work better/worse, and are worth exploring

<slightlyoff> JeniT: yeah, I think there are

<JeniT> for example, should you use data-* attributes, classes

Anne: we should also describe when the layering was not done right

and point to what would have been the right way

Web Components is considered generally as the right direction

Noah: we need a list of who needs to buy into this

Anne: CSS, WebApps, Webappsec, WHATWG...

Noah: should we invite them to meetings?

<annevk> WebRTC WG

<annevk> http://www.w3.org/WAI/PF/

<slightlyoff> it's an alternative declarative form that has more power

wycats: when you have an img tag, or xhr, you need to describe the layers involved here

Anne: in the case of a redirect, it's not clear that layers should be exposed or not

(discussion about high level apis of socket vs low level options like slow-start)

and their relevance today

<slightlyoff> you're construing my point as a strawman for only low-level control, which it is not

<slightlyoff> my point was more subtle

Alex: exposing only high level or only low level is not helpful, you need to explain their relationship as well

<slightlyoff> yes, and we will inevitably have both

<slightlyoff> and should!

<Zakim> ht, you wanted to ask about declarative layering

<wycats_> https://gist.github.com/wycats/5205250

wycats: if it's all declarative and not what you need, then it won't work, you need to have a programmative "escape" to work around

<slightlyoff> ht: I'd think of it this way: is it possible to implement your delcarative system declaratively all the way? If not, you probably need an imperative binding at SOME point

<ht> Absolutely

<ht> Just glad to see that both routes are on the table

<slightlyoff> ht: oh, no, that wasn't the goal to rule that out. We're advocating for both declarative and imperative forms in the platform for MOST important capatbilities

<slightlyoff> ht: yeah, we're not calling one or the other "the winner", just pointing out that they need each other and that they should have a relationship

<ht> cool

<slightlyoff> we can't all win unless both imperative and declarative move forward together

ES6 changes

wycats_: syntactic improvements
... can do { foo() { ... } } to define methods on an object
... (args) => { ... } instead of function (args) { ... }
... 'this' doesn't get bound in shorthand
... APIs that mutate 'this' are bad APIs: instead you should be passing along parameters

<slightlyoff> to provide some color, I don't necessarialy agree it's bad, but TC39 is constrained in syntax and semantic alternatives here -- I have argued in the past for "soft binding" that would allow for explicit "this" over-rides, but it's complicated and an edge-case

<slightlyoff> the big issue here is that in JS, the dot operator (e.g. "foo.bar") doesn't bind a function that's de-referenced with any particular this binding

<slightlyoff> this is a partial fix

<slightlyoff> for some subset of use-cases

wycats_: (item) => item.toUpperCase() auto-returns

var callback = [];

for (var i=0; i<10; i++) {

function () { console.log(i); }

callbacks.push(c);

}

<annevk> for(var i = 0; i<10; i++) { function c() { log(i) } push(c) }

<scribe> ... new binding form 'let'

UNKNOWN_SPEAKER: scope of 'let' is a block
... 'const' has same binding scope but can't be changed

<slightlyoff> this is the "temporal dead zone"

UNKNOWN_SPEAKER: but not expected to be heavily used
... "destructured assignment"
... var { type, bubbles } = options;
... var { type, bubbles=false } = options;
... var { type: type, bubbles: bubbles } = options;
... in this case, part before : is the key name in the passed object, part after is the variable to which that value is assigned
... var { type : { bubbles }} = options;

<slightlyoff> for folks who want to play around with many of these things, you can try interactively in Traceur: http://traceur-compiler.googlecode.com/git/demo/repl.html

UNKNOWN_SPEAKER: [ type, bubbles ] = array;
... [ type, bubbles, ...rest] = array;
... var { type, bubbles? } = options; means no error if bubbles isn't defined in options

<slightlyoff> http://traceur-compiler.googlecode.com/git/demo/repl.html#var%20%7B%20type%20%3A%20%7B%20bubbles%20%7D%7D%20%3D%20%7B%20type%3A%20%22thinger%22%2C%20bubbles%3A%20false%20%7D%3B

UNKNOWN_SPEAKER: this makes it more reasonable to have return values that are dictionaries or arrays

annevk: functions already return objects, and this will work with that?

wycats_: yes
... use destructuring method inside argument list
... function Event({type, bubbles})
... function foo(a, ...b) { ... }

<masinter> most of this stuff is just "syntactic sugar", though, no changes to the VM needed?

<slightlyoff> masinter: there are Object Model changes in ES6 too, largely thanks to Proxies

<slightlyoff> masinter: but much of what has been shown now is pure sugar, yes

<slightlyoff> masinter: also, in JS, there's no parser/bytecode split

<slightlyoff> masinter: we don't have a standard bytecode (and most JS VMs do without one entirely, although they do have IRs)

wycats_: function (a, ...b, { type, bubbles }) { ... }

timbl: think object parameters demonstrate lack of power in parameter list

wycats_: want implementations to optimise the destructuring

[discussion of keyword parameters]

wycats_: optional arguments
... function bar (a, b=1) { ... }

wycats_: lots of weirdness around prototypical inheritance

... new syntax for semantic inheritance

<slightlyoff> you can try this syntax in Traceur too

<slightlyoff> http://traceur-compiler.googlecode.com/git/demo/repl.html#class%20Blarg%20%7B%7D%0A%0Aclass%20Thinger%20extends%20Blarg%20%7B%0A%20%20constructor()%20%7B%0A%20%20%20%20super()%3B%0A%20%20%7D%0A%7D

UNKNOWN_SPEAKER: class Event { constructor ({ type, bubbles }) { ... } foo() { ... } }
... class ClickEvent extends Event { constructor(...args) { super(...args); } }
... "maps and sets"
... var map = new Map();
... var key = {};
... map.set(key, "value");
... map.get(key);

<slightlyoff> Maps and Sets, BTW, might already be in your browser

<slightlyoff> FireFox has an early implementation shipping

<slightlyoff> and Chrome has it behind a flag, IIRC

UNKNOWN_SPEAKER: var set = new Set(); var obj = {}; set.add(obj); set.has(obj);

timbl: could have a value that you can pass around / compare, but not print, for example
... which is similar to what we were talking about yesterday re URIs

wycats_: var symbol = new Symbol(); var obj = {}; obj[symbol] = 1; obj[symbol]

plinss: hash is based on identity of object?

wycats_: yes
... goal to have real private symbol, but it's complicated

annevk: the symbol can be retrieved from object?

wycats_: yes, by reflection

annevk: the platform needs real private stuff

wycats_: yes, but that isn't what Symbol is
... "Modules"
... most crucial thing for the platform
... import { foo } from "bar";
... foo is not on window or any global object
... real example is import { Event } from "web/dom";

timbl: can you use "http://..." there?

wycats_: yes, but no, you don't want to

timbl: I'm interested in this question, because as TAG we should defend using URLs for naming things
... there are lots of systems where the search path is a problem
... leads to pain, lack of interoperability, and security problems

wycats_: conversation is still open, but URIs here force you to get it off the network, which is a problem
... this is a good conversation to have
... we'd like to have a good strategy to use URIs, but now is not the time
... in web/dom.js:
... export class Event { ... }

annevk: so export is a module syntax?

wycats_: if you import, it's assumed you're pointing to a module
... there's a literal form which is module "web/dom" { ... }
... but that means you can't move the module file

noah: can you export anything or only classes?

wycats_: anything: variables, functions

noah: do you have to explicitly export each thing explicitly?

wycats_: there's a form that's export { x, y, z } but it might go away

JeniT: can you import everything?

wycats_: no

timbl: good

annevk: what if I export a function that returns a Document, but I haven't exported Document?

wycats_: you only need to have access to the name "Document" if you need to identify the object as "Document"
... you can get hold of prototype and make a new instance using that prototype
... without knowing it's called "Document" in the imported module

timbl: can I in the import statement change the name of the thing that's imported?

wycats_: yes, eg import { XHR : XHR2 } from "web/network";
... modules have static imports & exports
... so that we can transitively get dependencies, before executing the code
... can also do System.require("web/network") but it assumes module is already loaded

timbl: can I get hold of module itself?

wycats_: yes, syntax subject to change but import "web/network" as webNetwork;

annevk: so you could then get hold of everything

<slightlyoff> one way to think about this is that Module instances are a new core type; they're not Object instances

wycats_: yes, but you don't have the local binding for the name in that case
... it's a frozen object
... you can loop over it

<slightlyoff> ...except it has no Object.prototype as its prototype

<wycats_> Object.create(null)

slightlyoff: one way to think of it is that modules are a new abstraction type, that you'll only ever create through this syntax

wycats_: the module is an immutable, frozen thing which cannot change, unlike the global object
... "Proxies"
... pretty complicated but have simple understanding
... http://es5.github.com
... see Chapter 8
... contains [[GET]], [[SET]] are things that browser implementations can override but JS programmers can't
... now have var p = new Proxy (obj, { get: function (proxy, key, receiver) { ... } })
... let regular JS do what host objects could always do

slightlyoff: it means the magic that was done through IDL can now be written out in JS
... exposing the magic

wycats_: there are many places in DOM that are doing this kind of thing, like the style object

annevk: like element.style.background is something
... style is a long list of names in IDL

wycats_: ok, maybe this isn't a good example

annevk: but the platform should not use proxies

wycats_: yes, but this exposes what existing APIs are doing
... length properties for example

slightlyoff: it's a way of rationalising how the current magic be explained
... and how we might do it in the future if there is a legitimate reason for doing so

wycats_: there are C++ implementations of objects that are used internally
... like arrays
... can add a property to classes
... eg (not real syntax) Element[@@create] = function () { ... }
... that's native code
... but in JS I can do class MyElement extends Element { ... }
... so extend things that are native implementations

marcosc: are we sure that's going to work?

annevk, wycats_, slightlyoff: yes

scribe: though hard

"Wrap-up"

noah: photo is live on the web
... on http://www.w3.org/2001/tag/2013/03/18-agenda
... let's remind ourselves of what we're going to do
... and make sure that there's a balance of work across the group
... thanks to everyone: I think we've started to work together well
... there are 9-10 of us, about a third of us will be busy with day jobs at any particular time
... we should have 3-4 things that we're working on

annevk: there's one slot open for appointments

timbl: you can suggest who that should be
... there's no defined date

annevk: I think that should be Peter

timbl: I'm always open to advice

noah: so, the Layering project is wycats_ and slightlyoff

noah: JeniT working on fragids, urls in data, capability URLs & unhosted Apps
... ht on persistence of URIs & URLs in data

[reviewing actions]

noah: please change actions to 'Pending Review' if you want them discussed in next telcon
... it's what I use to generate agendas

<masinter> All of my action items disappeared, i guess they got reassigned

<noah> close ACTION-763

<trackbot> Closed ACTION-763 prepare response to last call feedback on Publishing and Linking.

<noah> close ACTION-764

<trackbot> Closed ACTION-764 arrange for expert review of Publishing and Linking last call draft.

<noah> ACTION-789?

<trackbot> ACTION-789 -- Yehuda Katz to with help from Anne to review TAG finding on application state and propose TAG followup to promote good use of URIs for Web Apps including those with persistent state with focus on actual examples -- due 2013-04-16 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/789

<noah> ACTION-786?

<trackbot> ACTION-786 -- Marcos Caceres to frame, with help from Alex, discussion of Javascript API Design Issues for F2F -- due 2013-03-04 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/786

<slightlyoff> thanks, only missed 30 seconds

<slightlyoff> hit "esc"

<slightlyoff> no objections

<noah> MC: Let it go

<noah> close ACTION-786

<trackbot> Closed ACTION-786 frame, with help from Alex, discussion of Javascript API Design Issues for F2F.

[decision not to follow up on API design issues]

<noah> ACTION-788?

<trackbot> ACTION-788 -- Yehuda Katz to frame F2F discussion of liaison with ECMA TC39 -- due 2013-03-07 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/788

<slightlyoff> we can re-schedule time for something along these lines later -- there's lot we did get to this week and more we can do when we get deeper with various WGs.

<noah> close ACTION-788

<trackbot> Closed ACTION-788 Frame F2F discussion of liaison with ECMA TC39.

<masinter> public-script-coord@w3.org should follow up on WebIDL

<noah> ACTION-791?

<trackbot> ACTION-791 -- Alex Russell to redraft proposed "status" section that TAG is suggesting for Polyglot -- due 2013-03-27 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/791

wycats_: I should have an action to get TC39 to do something about WebIDL

<noah> ACTION: Yehuda with help from Alex talk to TC39 about helping with WebIDL (agreed on Monday 18 March) - Due 2013 [recorded in http://www.w3.org/2013/03/20-tagmem-minutes.html#action02]

<trackbot> Created ACTION-792 - with help from Alex talk to TC39 about helping with WebIDL (agreed on Monday 18 March) [on Yehuda Katz - due 2013-03-20].

<noah> ACTION-791?

<trackbot> ACTION-791 -- Alex Russell to redraft proposed "status" section that TAG is suggesting for Polyglot -- due 2013-03-27 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/791

<slightlyoff> yes

<slightlyoff> I'm here

<slightlyoff> yep, LGTM

[noah writes 'polyglot' next to slightlyoff's name]

annevk: I'm looking at application state

<annevk> masinter: going through actions and such

<slightlyoff> members of the tag are also concerned