See also: IRC log
The following IRC handles and nicknames are used in these minutes:
| Handle | TAG Member |
|---|---|
| slightlyoff | Alex Russell |
| torgo | Dan Appelquist (former TAG member) |
| wycats | Yehuda Katz |
wycats: jQuery foundation, web developer since 2003
annevk: elected as individual, now at Mozilla
... was at Opera
... worked on selectors API, CSS namespaces, DOM, URLs, Fetch specs
wycats: works on TC39, module system, gathering use cases
... day job working on libraries
Yves: TAG team contact, and for WebApps
... worked on HTTP 1.1 & HTTPbis, CSS (esp validator)
... also web services
plinss: HP, CSS WG, full-time standards, was Netscape's rep
... started the CSS namespaces spec for annevk
<annevk> Yves, if it was up to me we'd remove the whole thing, but it was already too late :/
ashok: Oracle, XML Schema, XQuery, web services, linked data
... trying to standardise property graphs
JeniT: works for ODI, worked on XML Processing, Data & HTML, fragment identifiers
Larry: Adobe, LISP, networked-mediated communication
... URIs, URNs, HTTP 1.0 & related protocols
... HTML, when it was at IETF
... on advisory board for W3C & contributed to TAG charter
... in IETF, URI schemes
<Larry> http://larry.masinter.net
noah: For much of my career was officially IBM,
... but while there also spent time at Stanford, MIT, etc.
... split between industry & academia, went to Lotus
... work with IBM & Sun on JavaBeans
... contributed to XML & SOAP specs at W3C
... hard to do clean work in large standards arena
... appointe by Tim to TAG in late 2004, then as chair
... several years ago.
... nice tradition of having diverse opinions on the TAG
... (Note that Tim has often appointed people who disagree with him)
... now at Tufts teaching computer science
noah: agenda fluid, except that ht & jar only here after lunch tomorrow & Jeff at 11am tomorrow
... big things we will come back to on Wed
... we represent the whole community, not ourselves
... or our employers.
... should be aware of charter
<annevk> http://www.w3.org/2004/10/27-tag-charter.html
<annevk> charter ^^
noah: From charter:
... 1. document & build consensus around web architecture & to interpret & clarify principles where necessary
... help community agree on what matters & how pieces fit together
... 2. resolve issues involving architectural principles
... both brought to the TAG & proactively
... 3. coordinate cross-tech architecture developments inside & outside W3C
http://www.w3.org/2004/10/27-tag-charter.html#Mission
noah: we're not officially in the loop on spec approval
... will usually go direct to WGs about things we disagree with
... TimBL has ultimate say as Director
... one of our jobs is to be available to advise him on occasions when he has to make decision
wycats: when we ran, slightlyoff & I interpreted "web architecture" to include architecture of web platform
... it usually means how documents interlink etc
... there's more recent developments around how platform works
... there isn't a lot of architecture of the platform itself
noah: we've had several efforts, eg torgo's work on API minimisation
annevk: (to wycats) is your question about whether it means HTTP etc?
wycats: I'm asking about whether it means architecture of documents & their interactions
noah: web has grown from web of documents to web of other things, including active documents (ie scripts)
... we did try to rewrite web arch around web applications
<Larry> how the web works: what's a server, client, using HTTP, separation of markup and style, the role of javascript. the 'architecture' of something describes the pieces and names the interfaces for how they're put together
wycats: there's architecture of that web that is out there, and architecture of platform
noah: can we delay until later in the F2F?
... the community builds specs, web built on them
... the pieces should fit together so that the web has a set of characteristics such as scalability, internationalisation etc
... I want us to remember that our remit is broad
... eg whether we can use URIs as if they mean something in 100 years, something the library community is concerned about
... probably not so relevant to browser community
... my job to smooth things along & make sure we deliver
annevk: how important is the charter?
... eg it talks about using XML in a way that's no longer relevant
noah: not legalistic about it, but need to follow spirit
http://www.w3.org/2001/tag/2013/03/18-agenda#developersdevelopers
wycats: we'll have more luck outreaching to developers if what we do is stuff that affects their day-to-day lives
plinss: I have a proposal: there's the webplatform.org project
... maybe we could have an architecture section on that site
<annevk> http://www.webplatform.org/
<Larry> +1 to peter
noah: we have tried to do that previously, we assigned actions to do similar on the W3C site
... almost never did them
... is anyone interested in doing that?
<Larry> w3conf and webplatform.org represent new, significant addition of resources to build and maintain
<Larry> that's what's different
wycats: I'm not sure web developers would find value from it
noah: when I teach, I like to point people at those things
wycats: specifically, webplatform.org is not a good platform for that
plinss: I think it's evolving and it's trying to be that portal
... if nothing else, some high-level overviews
wycats: like a list of concepts? here's what a URI is?
<Larry> i think this is an area where tag members are out of touch, webplatform.org is just starting, hasn't been filled out
plinss: yes, and how to use it, just broad strokes
ashok: could you extract it from the web arch document?
plinss: yes
wycats: my sense is that if we want to educate developers about web arch
... they see it as it actually works, eg POST can be used to delete resources
... danger of telling people how it works when it is out of touch with reality
plinss: yes, you have to be pragmatic
... eg the hashbang thing is a hack
... we should document it, say it's a hack, show the way forward to the right way
wycats: yes, say that the architecture of the web *right now* involves the hack
plinss: yes, and show the migration path
<Zakim> noah, you wanted to talk about interaction vs. one way
wycats: calling out the things that work today but that are hacks
... particularly useful to know what bits are hacks
noah: right relationship with developers is a discussion rather than one way
... webplatform.org isn't right because it's one way
... been at our best when we've worked with others
... good tension between short-term focus & long-term view
... architecture is about taking long-term view
... it's really hard because you don't get the immediate feedback
... good architecture usually boils down to use cases, should be examples about what breaks
<wycats__> it turned out that it has poor adoption characteristics
annevk: important to understand why the confusion happens
... eg a elements don't have way of specifying method
noah: need to be asking the question "are we doing anything we'll regret in 10 years"
<Larry> i think talking about GET vs POST belongs to the HTTP working group and that it was a waste of TAG time to talk about it
wycats: bringing it back to topic of developer outreach
... think there's high leverage in reaching out to platform developers (eg Rails, jQuery)
... to make it easy for developers to do the right thing
... eg Rails team very interested in getting guidance on REST etc
... we still have to guess sometimes
... target the tools that people are using to build the sites
... this is about adoption characteristics, don't have to address everyone in the universe
<Larry> best instance of successful developer outreach was http://www.w3.org/conf/
noah: TimBL's design notes are a great resource, something TAG has done is write them up
wycats: it's not well known that eg the web arch document exists
<Zakim> Larry, you wanted to give a different description of "architecture"
Larry: architecture is about what pieces there are and how they connect together
... eg markup, style, scripting, client-server protocol
... principles are guidelines for how to use the architecture, or misuse it, things you should & shouldn't do
... as a result of telling developers about the fundamentals
... someone new to the web needs to understand how the pieces interact
... GET vs POST is at too low a level, not a great use of TAG time
... architecture has changed significantly since Tim designed it, because of introduction of AJAX, scripting paradigm
... HTML now an API with a little bit of parsing
slightlyoff: worth understanding economics that constituencies find themselves in
... touched on that around current constraints vs futures
... people are publishing content for parochial reasons
... want to create value for a set of users
... architecture enables or disables them from doing that
... want to maximise benefits & minimise costs
... have to be informed by what people are trying to get done
... second point is that AJAX isn't a completely different architecture
... means we have to recognise imperative layer
<Larry> "origin" and CORS need to be part of webarch
<annevk> Larry, working on it: http://fetch.spec.whatwg.org/
<Larry> annevk, "part of webarch"
<Larry> i don't mean "specified in webarch"
<annevk> Larry, fair enough
<Zakim> noah, you wanted to say why ajax does change things
noah: on AJAX, we have found places where it changes things
... eg one principle is identifying things with URIs
... question about "what do you identify using an AJAX app"?
... eg states in a game
... if it's something that would have been done using the normal web architecture, still want to use URIs
... same with web storage
... still need to identify these things with URIs
... these are architectural questions
annevk: when would you not use HTTP requests?
noah: some of the web sockets stuff for example
<Larry> i mean that there's no place in the current webarch to talk about 'origin'
<Larry> i think URIs are less important to webarch as they were 10 years ago
wycats: one way to address the concern around local storage is to ask how can we make it really easy to use URIs for that
noah: not everyone agrees that's even what we should be aiming for
wycats: naming things with URIs is a fundamental part of the web
noah: let's have a proper session on URIs, AJAX etc later
slightlyoff: wycats, annevk & I have done work on this we could discuss
wycats: this is something that developers do understand, but they don't understand what it means to have a URI for an AJAX app
... so this is something where we could have a good impact
<Larry> i think "is it OK?" formulation isn't useful here
<slightlyoff> it IS a capability system
<Larry> noah: people use URIs for capabilities. it's part of how wthings work
<Larry> secrecy is measured in time-to-expiration
<Larry> uris can be secret for a little while
<Larry> time-to-compromise
<Larry> some really well encrypted channels have a time-to-compromise of decades (some people believe centuries, but i don't believe that)
<Larry> webarch also needs security properties everywhere
http://www.w3.org/2001/tag/2013/03/18-agenda#layering
<wycats__> Here is the deck: http://cl.ly/3P3K3C3E422C
<slightlyoff> heh
wycats: trying to unpack what we meant by "Layering" when we ran for TAG
... watched TimBL's TED talks
... wanted to talk about how AJAX stuff links up with linked data & open data
... first documents were hand-written documents, like we post via CVS
... the data is the same as the markup, no translation layer
... people realised they didn't want to have to write everything by hand, so started to separate out data and template, combined to create document
... this obscures some of the raw data
... as JS came into the frame, even the document provided via HTTP doesn't include the content
... now need to run JS to get the "content" of the document
... less and less of the document is content, more and more generated by JS
... other side of this is that it's the *data* that is published by the servers
... the semantic content is exposed
... JS is about displaying that semantic content to the user
... going to show discourse, form software built as a JS app
... URL friendly, but all the communication is done via APIs
... downloadable page is nothing (nothing in HTML)
... rich semantic JSON sent to the client, devoid of display semantics
... other end of the spectrum from markup is data, end up doing API first development
... should be excited about this development if you like linked data
... we shouldn't be scared of JS
... "Where We Are Today"
... people writing specs are writing implementations, think in terms of implementation
... platform capabilities are exposed via markup & DOM bindings (JS code)
... markup mapped to DOM, JS code interacts with it, display doesn't link with that JS bindings
... JS bindings & rendering don't interact
... eg simple form for POSTing info about people
... the HTML spec defines how the input fields are displayed
... one big case statement
... want to add something new, have to add a new case
... problem is that if you want to build your own controls, eg date picker
... algorithm doesn't delegate to you
... specification mirrors implementation rather than well-designed architecture
<slightlyoff> indeed, serialization is pluggable inside most implementations!
timbl: you're making assumption that you want to burrow all the way down
... even if it was implemented in JS it can be an architectural feature that you can't control everything
<slightlyoff> nobody's arguing against the value of standards
<slightlyoff> at least not me or wycats__ ;-)
wycats: the answer isn't that "everything is JS"
... custom controls in jQuery
... create some hidden markup & use script to make it behave the way you want to
... serialize() in jQuery, to create form submission
... need to write lots of imperative code to hack around the constrained browser capabilities
... people end up writing the whole browser in JS
<slightlyoff> other toolkits do exactly this
<slightlyoff> (i've written this code multiple times)
<slightlyoff> I also wrote this code in Dojo
<slightlyoff> (the serialization system)
<slightlyoff> Closure has the same split
wycats: "Appeal to Magic"
... form serialisation is the exact implementation in C++
<Larry> is SVG as its own content-type part of webarch?
wycats: people understand the core value propositions of the web, work hard to implement them in script
... people don't do everything in canvas, but write lots of JS to emulate stuff that's part of the core web platform
<slightlyoff> once again, I can attest to this from the perspective of Google properties
wycats: URLs update as you scroll down the page
noah: this is a great example of what we've been advocating
wycats: the amount of JS necessary to do this is 962kb
... would prefer to hook into primitives of the platform to get this to work
... people discontented with having to write so much JS to do what should be built-in
... "so close and yet so far"
... in Rails we have something that reimplements browser navigation using XHR
... to get better performance
... end up doing crazy hacks to augment what the platform is doing
<timbl> https://github.com/chad/turbulence
wycats: users are frustrated when emulated layers don't work well
... examples of twitter & Facebook, falling back from emulation
... big picture of twitter going to native web pages is that they are giving up on good user experience
... twitter/Facebook say "if you want to have a good user experience use a native app"
<slightlyoff> put another way: taking control, today, means taking *everything* under your JS-driven roof
<slightlyoff> tweetdeck is still native on their native platforms
<Larry> tweetdeck was Adobe AIR
<slightlyoff> (iOS, Android)
<slightlyoff> it's HTML5 on web.tweetdeck.com and their Chrome app
<Larry> http://en.wikipedia.org/wiki/TweetDeck
<timbl> http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html
timbl: one of the things here is page load time, comparing that to a local application is cheating
... need to install the app locally to get the speed
wycats: they were using caching etc, so trying, but you still have first page load hit for people finding tweets via google
... web is a more casual browsing experience than the installation of applications
... do not expect to have to install when they hit pages
annevk: where does twitter advocate using native apps?
wycats: not in this blog post
annevk: how do we get both the speed and the user experience?
wycats: I'm getting there
noah: two problems: having to download loads of JS & having to write loads of JS
wycats: reasonable to have a more installable model
... size is a particular issue in mobile & outside developed world
... shouldn't underestimate cost of malaise, result is less engaging apps
slightlyoff: speaking from Google experience, eg desktop Gmail on the web
... something like megabyte of JS, mostly is stuff the web should be better at
... spent an enormous amount of effort to reduce load time & impact of the wait
... the constraints are the same even for massive organisations like Google
... can't do as much as a native app can
<Larry> does TAG want to take on web performance? takes optimizing rendering, download, network latency, javascript performance. "Velocity" conference
wycats: looking at popular apps built using backbone/ember/angular
... apps are around 700k
slightlyoff: limits are much lower on mobile devices
wycats: "Turing Escape Hatch"
... people ask for primitives
... example of mouse vs touchpad
... eg tapping on iPad vs with mouse --- no :active on div
noah: this is about mapping that browsers have chosen in iPad
wycats: can add .active rather than using :active to hack around it
...: active applies when "the element is being activated by the user"
... this is appeal to magic
annevk: we have talked about how to spec this
... complexities around scrolling
... these are HTML4-era specs
wycats: even in more modern specs there are huge failures in layering
... there's a theory of layering that leads us to do the right thing
noah: I assume that these specs were written when the impact of iPads etc wasn't clear
... could people have gotten this right?
<slightlyoff> yes
wycats: there should be some JS property somewhere that says that an element is active, so you can call it
slightlyoff: in the implementation there is an imperative version of this declarative form
... the question is how exposed is that declarative form to the imperative world
... there's going to be a translation somewhere
... it's straight-forward to say that you need to add the imperative form at some point
timbl: by explanation, you mean you must be able to reroute the code
wycats: you must be able to not appeal to C++
noah: you need to be able to keep some of it, need to choose where you have the layer
... end up with huge UI frameworks, where the purpose is to theme etc
<annevk> (I think the main problem is that we don't even understand, in documented manner, what the actual user interaction model is. User agents reverse engineer this from each other at the moment.)
wycats: platform built around C++ DOM
... "Fundamental Theorem of the Platform"
... "Markup begets JavaScript objects via a parser"
... should be theorem that explains what the platform is doing that helps us define declarative/imperative split
... stack of markup, JS runtime, DOM standard library, rendering
... rendering defined in terms of platform primitives eg canvas
... this matches web developers' mental model
... gives us reasonable hook
annevk: this doesn't allow for asynchronous selector matching
wycats: this isn't getting 100% perfect, just getting magic part smaller
slightlyoff: creating a competitive platform, we have technical question of accomplishing most value with least effort
... not about replacing everything, about doing archeology & explaining in terms of more primitive APIs
... some might not be exposed, but this is a powerful exercise in creating generative platform
noah: in these architectures, one thing you might want to do is encouraging people to do the XML thing and creating lots of new tags
wycats: yes, that's what I'm getting to
... "Path for Natural Platform Evolution"
... we don't want people to write everything using these primitive forms eg using canvas
... provide some markup, people write imperative extensions, new "slang" markup, broad acceptance
... we want to allow people to experiment with new tags
... if they become acceptable, they get rolled into the platform
... provide a mechanism for evolutionary development that doesn't rely on Hixie
... can look at pages on internet to see what's being used
<slightlyoff> more to the point, we can't prevent it
<slightlyoff> and haven't so far
<slightlyoff> here's a preview of what that reserach might look like: http://meaningless-stats.appspot.com/global
<slightlyoff> https://github.com/slightlyoff/meaningless
noah: would you encourage people to experiment with tags that might become part of the platform, where's the cut-off about what you can use
timbl: what if you have a serious community eg MathML & Geo communities
... broad acceptance in their communities, but not across whole planet
... what's the world in which there are pieces of these?
wycats: I would imagine they would create their own extensions
timbl: would it be a browser extension?
wycats: can imagine in different levels of broad acceptance leading to different levels in browser support
timbl: I'm particularly interested in things that are completely accepted in a small community
wycats: the question is at what point it gets pulled into C++ code
<noah> I mostly like where Yehuda is going, but I'm nervous about the ability to (a) encourage communities doing things like MathML to standardize while (b) telling dentists that a <jaw> tag is not what this is about. One persons's horizontal can be another's vertical.
timbl: there are lots of communities doing exciting things
... like the geospatial folks, but they will not ever get into every browser
<slightlyoff> the point is we're not doing this with data today
<slightlyoff> we're doing conjecture, not science
<Larry> "chemical ml" and "math ml" are good examples
wycats: they could just have a JS library
... or they could have a browser extension that would make available & cache the JS library
timbl: and maybe reimplemented in C++
<noah> This might well lead us back to and XML-like architecture, albeit with dynamic Javascript support (which is cool), but without namespaces or a distributed extensibility model.
<noah> I might agree that living without something like namespaces is OK for things that may become core to the platform, when you get too close to vertical (dentists), you really need some way to keep names straight, and to enable mixins.
slightlyoff: I posted a reporting site for a Chrome extension to start looking at the ad-hocs semantics in the web at the moment
... we haven't stopped anyone adding semantics to HTML
... we've made it difficult enough that people don't agree on how to express them
... the goal is not to repeat the perceived mistakes of XML world
... it's to generate the visual/content meaning from the markup
... we don't have today a good way to tie the creation of end-user value to new declarative forms
... hard to track use of declarative form because people use imperative form
... give tools to start declarative
... can then start to do science on the web to detect patterns
... at the moment we can't do this because it's hidden in the imperative code
<slightlyoff> this markup system, btw, is my work from Web Components
<Larry> JSON is a "declarative form"
wycats: an Ember template looks like a minified JS function, for example
... final example is different from markup
... offline downloadable case
... step one was App Cache
... Apple used this at beginning of iOS
... App Cache declarative form with no imperative escape hatch
... Hixie built declarative form
... large number of workshops to fix what's broken with App Cache
... Hixie wasn't interested in implementing it
... platform already has capability, but because it was drafted wrong, we're not able to use it
... if there's no escape hatch we can't easily fix/hack around these
<Larry> public-fixing-appcache@w3.org
<Larry> http://www.w3.org/community/fixing-appcache/
<slightlyoff> you weld it shut if your view is that the platform is a hermetic thing without layering
wycats: need platform features that are broadly useful rather than targeted on specific features
... "Navigation Controller"
... questions when you write an offline app
... what happens when they first load the page, first time, subsequent times, how does the cache work?
... Navigation Controller provides the answer, but also way to override
noah: is this defined in terms of an HTTP cache?
slightlyoff: no
... turning big case into small primitives, if they're not implemented fall back on default behaviour
wycats: App Cache implemented on top of something where behaviour can be overridden
noah: HTTP caches are implementations of HTTP spec, built into browsers
... not focused on long-term caching
... be interesting to tell an organised story about how what we do relates to those headers and that architecture
... should be a lot in common
... need a clean story where this is consistent with this architecture
annevk: need to define the interaction anyway
noah: look at both spec and code point of view
wycats: I think it does talk about interaction with HTTP cache now
annevk: if there's a POST, you want to store it in the Controller in the offline case, which HTTP caches won't do
wycats: use existing browser primitives, build on top of them
... need core primitive of "opaque response" for example
... we might not like how it works, but we need to explain how it works
ashok: is this how you think it *should* work, or how it *does* work?
wycats: this is a proposal that Alex is creating, a proposal that Alex will make to a real WG
... "Declarative Form"
... Jonas Sicking has been working on better declarative API
... it's a JSON model
... one problem with App Cache was that it wasn't extensible
... using JSON means we don't have to amend the parser
... it's less ambitious
... provides just the obvious things, so we can explore how it is actually used
... includes mechanism for templated URLs & use of XHR
... lets you point to markup & data separately
... "Evolution"
... people will extend JSON, add JS libraries etc
... use this to evolve the platform
... better imperative capabilities enables better evolution
... I'll not talk about web components much
... these are basically the same thing
... I propose that we write a Recommendation that outlines this design philosophy for the web platform
Yves: going back to delegation controller & cache
... if you look at local cache as being a URI resolver, then you see it as a low end version of a controller
... there are things that are shared
wycats: yes, you could imagine that HTTP cache is defined as controller
noah: need few minutes discussion about where to go next
... this would be a significant project for the TAG
... for these we should have a project page:
... goals
... success criteria
... a Rec is not a success criteria: explain in terms of what that achieves
... key deliverables, dates, who's assigned
... often useful at this point to create a first cut at what the product page might look like
... use that as point of discussion about why we should do this, what the TAG's role is
<noah> Example of a product page: http://www.w3.org/2001/tag/products/fragids.html
wycats: all this stuff about Navigation Controller etc is just specific examples, we need to look at higher level
timbl: what's the push-back that you've heard around these ideas?
... will the implementers get on board?
wycats: main pushback is from people worried about new declarative forms
<noah> If this is to be a significant project, we need a plan at about that level. We don't necessarily need it at this F2F, but I'm suggesting we draft a strawperson version just to get discussion of what the scope and goals of the TAG's work on this might be.
slightlyoff: general lack of familiarity from implementers about what developers need
... don't go from being web developers to browser implementers
<wycats__> noah: I volunteer to bring that back tomorrow or Wednesday
<noah> Great, thank you. Suggest you collaborate with others, at least informally.
noah: great, we'll come back to this later in the F2F
annevk: the main concern I've heard about web components is lack of shared understanding
... counter-argument is that we already don't
... also heard concern that if we only do low-level primitives, it'll be too hard for normal web developer
timbl: building up from bottom rather than down from top?
<wycats__> you do both
<wycats__> but the high level is defined in terms of the primitives, like the app cache example
slightlyoff: this is an interesting question for the TAG: do you do one before the other?
... look at what opportunities you foreclose and how you reduce opportunity for harm
timbl: like with :active you could imagine it starting with touch events etc
... need some top-down for device interoperability
... if you start low-level people start generating different design abstractions
wycats: define high-level in terms of low-level
... eg start with the element, then talk about what new capability is in JS objects
... end up with high-level thing that's nice + escape valve
timbl: if you get it right, yes
annevk: another concern, around rendering, is that rendering doesn't happen on main thread
... currently constraint-based system rather than imperative system
... exposing it as a imperative system removes possibilities of optimisation
noah: try to keep as much of it as declarative as possible
... eg changing CSS through adding class through JS
wycats: always going to be the case that if you are reimplementing something that's implemented in browser it's going to be slower
annevk: by defining the platform in a certain way, you might constrain it
... might want to implement browser in a fancy different way, the single-threaded system is problematic
<slightlyoff> annevk: http://infrequently.org/12/cassowary-js-refactor/demos/css/canvas-renderer.html
timbl: these sorts of problems: making something performant needs different implementation strategies
... eg parallelisation
... asking for the callout can be difficult to implement
wycats: people are reimplementing the entire layout system in JS, surely that's not more performant
timbl: so prepared to hit on very fast reflow of CSS in order to be able to override it
<slightlyoff> annevk: it's possible to uncover the solver as a capability
<slightlyoff> annevk: going where the evidence leads
<slightlyoff> annevk: without pre-judging the level of abstraction you end up at
<annevk> slightlyoff: I meant e.g. the case bz mentioned where if you implemented the DOM completely in JS you could no longer do async selector matching
<slightlyoff> yeah, that's sort of BS
<annevk> slightlyoff: I don't really fully understand canvas-renderer.html
<slightlyoff> browsers always have fast-and-slow paths
<annevk> slightlyoff: euh sure
<slightlyoff> annevk: it's re-implementing CSS in JS via a JS constraint solver that I work on
<slightlyoff> annevk: but the conceptual level of abstraction need not be one level or the other
<slightlyoff> annevk: e.g., JS engines internally use single-static-assignment transforms
<slightlyoff> annevk: but JS is not a pure-functional language
<slightlyoff> and there are scenarios where you can't employ those xforms
<slightlyoff> and we get by
<annevk> I don't follow
<slightlyoff> going fast when we can based on some other formalism than the naive interpretation of "what it is"
<slightlyoff> +1!
<ht> I wonder if there's a place here for what the XML-on-the-Web community has been doing for years has a place in this story, i.e. _declarative_ layering using XSLT in the browser
<annevk> scribenick: annevk
http://www.w3.org/2001/tag/2013/03/18-agenda#fragids
goals for this session: http://lists.w3.org/Archives/Public/www-tag/2013Mar/0059.html
JeniT: Goal of this session is to figure out what to do with the spec
[see link above]
<JeniT> http://lists.w3.org/Archives/Public/www-tag/2013Feb/0021.html
JeniT: RDF/XML clashes with RFC 3023bis
... If you have a structured syntax like +xml or +json, then any media types that adopt that suffix need to comply with the suffix registration
... generic XML processors should be able to use fragids without understanding context
<JeniT> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2013-03-12.html
JeniT: the spec (^) is written for four sets of people
... registration of +suffix media types people (e.g. +xml); media type registration people (e.g. application/rdf+xml);
... fragment structures which should work across media types
... and the people who write code
<ht> Relevant bit of 3023bis is here: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-8.1 and here: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-5
JeniT: Last Call was the last step
... now up for CR for which we need exit criteria
wycats__: my main issue is that in browsers fragids are often used for something else entirely
JeniT: the focus is not for RESTful app developers as that's addressed elsewhere
timbl: don't you think the use of fragids might increase?
wycats__: seems plausible
... My concern is that a document about fragment identifiers should cover its main use, in HTML
<ht> See also http://tools.ietf.org/html/rfc6839#section-4.1
JeniT: it's up to the media type registration
<slightlyoff> I see this as a question about navigation
annevk: I think there's a mismatch between the media type -> fragment mapping and what actually happens in a browser
noah: is this in the edge case or is this not the architecture?
... is this 80/20 or is the architecture really not correct?
annevk: I think it's a 80/20
<JeniT> discussion about embedded images in iframe etc where browser captures control of the interpretation of fragids within that iframe
noah: is it okay if we note that we point out it's not always accurate and we might do future work?
Ashok: what if somebody does a registration and does not follow the rules?
Yves: best practices still allow for people shooting themselves
JeniT: media type registration people could check against this
Ashok: does the IETF agree with us?
JeniT: the feedback from the people involved suggests so
... but they are not the reviewers of media type registrations
... the exit criteria are what's important here
... [goes through proposal]
<noah> Two tentantive agenda items added for Wed morning. See http://www.w3.org/2001/tag/2013/03/18-agenda.html
plinss: CR is a call for impl so people should start using it
<slightlyoff> uh...I think wycats__ had a point ot make
<slightlyoff> we have time.
<slightlyoff> (all day, in fact)
wycats__: A thing that happens in the world in the world where people request the same resource from a browser and with an Accept header via XHR to get JSON
... if they use the same fragment, is that a problem?
... I want it to be specifically allowed to use a fragment identifier for some media types and not others
... in the context of content negotiation
<scribe> scribenick: scribe
<annevk> wycats__, so many reasons not to do content negotiation btw: http://wiki.whatwg.org/wiki/Why_not_conneg
<slightlyoff> annevk: conneg happens
<slightlyoff> annevk: honestly, it does
<annevk> doh
<slightlyoff> consenting adults and all that
<annevk> All I'm saying is that it's a bad idea
<annevk> E.g. confused proxies that don't support Vary
<wycats__> annevk: O_O
<slightlyoff> and I don't happen to agree = )
<wycats__> I disagree strongly with that document
<slightlyoff> in the same way I disagreed with crock's jslint recommendations
<annevk> wycats__, hope you read it first :)
<wycats__> And Rails/jQuery is an existence proof that this is not an issue
<wycats__> annevk: I did
<wycats__> I skimmed
<slightlyoff> annevk conneg drives a huge amount of the web
<slightlyoff> annevk I think your document is simply a dead letter
<annevk> slightlyoff it's not mine
<annevk> slightlyoff I simply agree with it
<slightlyoff> annevk ok, still a dead letter = )
<slightlyoff> annevk and agreeing with it want revive it
<annevk> slightlyoff I don't think it's dead at all
<annevk> slightlyoff most of the new stuff has taken it into account
<slightlyoff> annevk sorry, it might reflect your reality but not most of the web, toolkits, etc.
<slightlyoff> annevk so specs might write it in, but it doesn't make it right
<annevk> slightlyoff most of the web, I'd like to see that quantified
<annevk> slightlyoff e.g. most of the CDNs don't work this way
<slightlyoff> annevk by traffic? sure: gmail and google.com search
<annevk> slightlyoff they use the same URL with different representation?
<slightlyoff> annevk you bet
<annevk> hmm
<annevk> scribenick: annevk
Larry: your CR exit criteria proposal looks fine
<Larry> the exercise of thinking about exit criteria is important
<Larry> it matters less about the details but at least that there is some credible measure that you "got it right"
<Zakim> ht, you wanted to point to the IETF state of play
ht: this implements the best practices
<JeniT> http://tools.ietf.org/html/rfc6839#section-4.1
<JeniT> http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00#section-8.1
ht: RFC3023bis has stalled due to lack of energy, but I now found that energy
<ht> http://tools.ietf.org/html/rfc6839 uses prose taken indirectly from earlier drafts of our doc't, and I think it can be counted as evidence of uptake wrt CR exit
<Larry> the "elephant in the room" is that MIME in the web is under attack by sniffing and registerContentHandler
<JeniT> browsers should implement http://tools.ietf.org/html/rfc5147
timbl: I'd like to use fragment identifiers to be used in lots more places
... e.g. I want fragment identifiers for plain text and view-source:
<Larry> +xml vs +json don't have common fragment identifiers
wycats__: Getting agreement on how to do this for text/plain might be tricky
timbl: My concern is that fragment identifiers are already in use in HTML for wildly different things and if we ask for them to have the same semantics as their you're breaking things.
<noah> I think the worry is conneg, Henry
timbl: http://tools.ietf.org/html/rfc5147
<ht> I think it's important to keep the conneg issues and the suffix/generic issues carefully distinct
<Larry> polyglot fragment identifiers
<Larry> fragment identifiers that mean the 'same' when interpreted by content with different media types
<ht> There are similarities, along the lines that Jeni has just suggested, but they aren't the same
JeniT: I think
... we agree on the exit criteria
... we agree to REC
... there are concerns with
... content negotiation and transitioning
... HTML/XML where script takes over the interpretation
... I will
... create a new draft for a future TAG call soonish
plinss: do these changes require another LC?
noah and JeniT: no
<slightlyoff> I don't think we need another LC
<JeniT> ScribeNick: JeniT
<noah> http://www.w3.org/2001/tag/doc/mime-respect-20060412
annevk: TAG finding 2006 on "Authoritative Metadata"
... argues that encapsulating metadata about content is more important than the content
timbl: that you can't understand content without having read it
annevk: in fact, browsers disregard content type sometimes
... they look at content type and sniff content as well
... because use the wrong content type
... with img, the content type is basically ignored
... test if it's image/svg, otherwise just pipe to image processor
... video is similar, uses the bytes in the content to determine format
... cache manifest does the same thing
noah: is there a lot of badly served video?
annevk: video is hairy because of how it's distributed
... lots of different container formats
... doesn't map that well to media type system
wycats: was a time, cache manifest was served wrong
annevk: with cache manifest we required correct media type, but people complained a lot, so we dropped the requirement
... with subtitling, the webTTL format, we also decided to just look at first set of bits
... we disregard content type for the response for these requests
... fonts, same thing happens
... tried to do fonts/X but IETF didn't help
... browsers started shipping
... people were using application/octet-stream
... IETF had no interest in fonts/X
... for CSP it's important
s/CSV/CSP/
scribe: content security policy
... trying to prevent XSS attacks
<slightlyoff> wait...what's important for CSP?
<slightlyoff> hmmm
<slightlyoff> I'm not sure I agree
<slightlyoff> I'm contributing to CSP
<slightlyoff> and I don't understand how this is an issue
scribe: from a browser perspective, we wanted to enforce content-type
... from a web developer perspective it's difficult
... because you don't always have sufficient control
<Larry> talking about sniffing?
marcosc: github doesn't give you any control for example
<noah> e Hi Larry, we're just getting into authoritative metadata. Anne is giving us a summary of the state of play, which is basically: a lot of the new markup specifically ignores content type in some cases due to pushback when early versions required it
annevk: we don't want to interpret arbitrary files as CSS
... there were hacks that took advantage of that
... for cross-origin requests we enforce content type
... and in strict mode
... CSS is easier to enforce because it's been around for a long time
<Larry> x-content-type-options: nosniff is a good idea
<slightlyoff> again, would like to dive into CSP
slightlyoff: I'd like to dive into the CSP question, because I don't understand the issue
... CSP defines what origin what sort of content can be from
... that's about execution
... that doesn't speak to mime types
annevk: CSP is authoritative metadata
... we want that metadata to be authoritative
<noah> Curious, is content-type honored on script tags?
slightlyoff: I see, you're not talking about content type here, you're talking about the CSP header
noah: we're on a thread with darobin saying that authoritative metadata is an anti-pattern
<slightlyoff> I don't see how <script> is bad either
<slightlyoff> sending an image and having it pulled in is just fine
<noah> Quoting from Robin's email of http://lists.w3.org/Archives/Public/www-tag/2013Feb/0114.html
<Larry> there are a ton of problems with the sniffing document
<noah> "I would support the TAG revisiting the topic of Authoritative Metadata,
<noah> but with a view on pointing out that it is an architectural antipattern. "
annevk: there's an argument that we should be looking at something else because it's not working
<noah> So, the suggestion that it's an antipattern comes from Robin, and that's in part what led us to discuss today.
marcosc: the thing in github is that when you navigate to the raw file in github, it's served as text/plain
... if I have a type that I'm working on, there's no way of registering it in github
<slightlyoff> FWIW, CSP is only authoritative in a modifier sense; the document is still valid HTML without the CSP restrictions
<Larry> people would fix their servers if browsers rejected mislabeled content
<slightlyoff> so CSP is strict subsetting, not type changing
<Larry> supporting "nosniff" would be a way of making metadata authoritative
wycats: web reality is that people don't have a lot of control over their deployment environments
marcosc: when I read the finding, the assumption seemed to be that there was a user and someone in control of a server
... and the most common case now is that you don't run your own server now
<noah> So, all this tends to confirm me feeling that the virtues of Postel's law are way oversold. If we were stricter about what we accepted from the start, we'd have lots more correctly typed content, and the Web would be a much more reliable source of information.
wycats: same with CloudFront
<Larry> i submitted specific bug reports on the sniffing spec
marcosc: my blog is another example, things are getting proxied all over the place, I don't have a lot of control
... I'm not going to be able to influence what that service is doing
wycats: there are some cases where you should care about authoritative metadata and some cases where you shouldn't
<Larry> authoritative metadata needs fixing
annevk: the specs capture this but the finding doesn't
slightlyoff: CSP is different than other metadata
... it's strict subsetting
<Larry> https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=MIME&resolution=---
<annevk> I think CSP might have been a distraction :-(
<annevk> I just mentioned it as something we want to be authoritative
slightlyoff: removing the CSP metadata from a document might functionally invalidate it, but doesn't otherwise change its interpretation
... it's ignored on browsers that don't support it
... it's best effort
<Larry> i think the general principle of metadata might be different for content-type charset
<Larry> http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff
annevk: once it's supported in all browsers, you have to use it
wycats: CSP doesn't give you 100% protection for all users
slightlyoff: it doesn't modify the type of the document or create an alternative processing path
wycats: you can't say "onclick=" in certain CSP modes
... if you turn off eval for example, it's application/javascript minus eval
<Larry> servers should send no content-type rather than a wrong one
noah: it's not changing the feature list, it's just disallowing some of the features
timbl: you brought this up as somewhere that sniffing is not done
annevk: yes, it's not that authoritative metadata is an incorrect finding
... we still use it for CSP for example
slightlyoff: it's not authoritative, it's best-effort
wycats: from the perspective of a client, it's not best-effort
annevk: another example would be X-Frame-Headers
... places where the metadata *is* authoritative
... or with CORS, we have to trust the headers
... not looking into content to see if headers are wrong
<Zakim> noah, you wanted to say it's not only the browsers
noah: I know that this is going to come up again and again
... over the next few years, we're going to have to discuss server<->browser vs one in which content is served, and browser is an extremely important use case
... we don't know what's going to be reading this in 20-30 years
slightlyoff: we're still going to be using browsers in 20-30 years
noah: we'll probably be using browsers for a bunch of things we do today
... but HTTP is usable for many things beyond page browsing by humans
... like google crawlers
... in general, HTTP and URIs are important infrastructure
... it's like saying that the telephone system is only going to be used for telephony
<slightlyoff> googlebot is TRYING to process the world the way users do
<slightlyoff> that's all it doe
<slightlyoff> s
<slightlyoff> that's its job in life
wycats: there's a common ubiquitous user agent, which is a browser
noah: that's important, but I want to talk about what servers should do too
timbl: the spec is a contract between client and server
<slightlyoff> noah: googlebot's stated mission in life is to process and "see" the web the way users do
<Larry> windows does x-content-type-options: nosniff, that would let metadata be authoritative
timbl: I wonder whether we should define two webs: a simple one in which authoritative metadata is a platonic ideal
... it's easy to teach someone how it works
... in fact there are variations
... a much larger book
... for a lot of the web, you can ignore the authoritative metadata issues when you're designing websites
... maybe it's useful to have both
... authoritative metadata is a model
... just as it's useful to have an HTML spec which is "these are the tags"
... maybe we need two documents
<slightlyoff> what's the use in a toothless finding?
<wycats__> it's easy to teach people lies
<wycats__> people do this all the time
<wycats__> throughout the world
annevk: that question hasn't been answered
... should we recommend people use mime types for fonts, even though we know that clients will ignore them
... there's a mime type for app cache manifests, for example
... we could encourage its use and flag it in the console if the wrong mime type is used
... we could indicate in the browser the mismatch
<Larry> the MIME types for fonts are a mess
<slightlyoff> Larry ; sure, but does it matter?
<slightlyoff> that's the only question that seems to be at issue
<Larry> yes, slightlyoff, the font people tell me they have lots of problems
<Larry> there are awful workarounds
marcosc: you get console warnings for some mismatches in Chrome
... I have a JSON-based format, I want it to behave in a particular way
... what do I do?
... I need some authoritative metadata there
... JSON doesn't provide a way of giving a magic number
... no comments or any other way of including a magic number
... XML is different because you can use a namespace
slightlyoff: the mission of googlebot is to represent to users through search results what they would have chosen as humans
... we do everything we can to view the pages as a human would
... googlebot is necessarily browser-like
... systems that have to answer questions for humans need to see the web as humans do
<noah> Yes, Alex, I acknowledged that the Google Bots are focused on matching what would be seen through a browser, at least for now. If Google Bots ever want to help you find linked data, that might change.
<slightlyoff> noah the bots are trying to help you find linked data today; see schema.org markup
<slightlyoff> noah but that's just a sub-axis of the human-visible content we already try to make sense of
slightlyoff: second point: the question that marcosc raised
... is the question that you have a processor that doesn't know what to do with it?
marcosc: the pattern now is to invoke it through an API
... concretely I'm thinking of the Firefox hosted application model
... you install by pointing to a JSON file
... and what should happen if someone gets hold of that URL and pastes it into the location bar
... the bigger question is that we have these annoying formats that don't allow magic numbers
... and we need to be able to deal with those as well
noah: yes, and we always will
<slightlyoff> I can't speak for the crawl team and their interests, but our anti-spam techniques generally boil down to "you can't lie to us, show us what you'd show a human", so that's a hard constraint in the real world
wycats: the authoritative metadata finding is being ignored by the most popular user agents
... I think we should recognise that there are good reasons for user agents to ignore it
... also it's not a good platonic ideal if it doesn't work
<slightlyoff> agree with wycats__
<Larry> "Authoritative Metadata" tries to accomplish too much-- combining all kinds of metadata. The question si really "cascading metadata"
timbl: the point of the platonic ideal is that it's a sketch or a pattern that is easy to understand
... there's the Content-Type model, the FTP model of understanding the file extension, and the magic number world
... unix pre-Mac used file extensions officially but could sniff things
... in the early web, people got stuck on the extension
... in the browser, do you look at the suffix?
annevk: very rarely
<Larry> sniffing sounds better than labeling, but sniffing can't be made to work, because the ambiguity is INRTRINSIC for polyglot, puns, and intrinsically unreliable.
<Larry> if you are going to standardize sniffing, then you might as well put the sniffing in the server rather than the client
timbl: when you say "the most common application is the browser"
... the browser is lots and lots of different clients in different situations
wycats: I can imagine a universe where a platonic ideal spec is useful, but it shouldn't say MUST or MUST NOT
timbl: what about talking about patterns?
wycats: if we write something about Content-Type, we should look at what has actually worked
timbl: if you removed everything about Content-Type in browsers, it wouldn't work
annevk: we can't remove it at this point, HTML and CSS there's nothing you could use (to sniff)
wycats: in the user agent, it's very very common not to do it
... even recently, with fonts and manifests it hasn't worked
<Larry> "platonic ideal" is a incorrect reference
<Larry> Plato has nothing to do with this ideal
timbl: we've got these three patterns
... it's not an anti-pattern
annevk: darobin rolled back from saying that
<wycats__> I agree that it's not an anti-pattern, but I disagree that we should try to tell people that it's the one true way to do things
<wycats__> and the current spec irretrievably says that
<Zakim> Larry, you wanted to give pointers to background
Larry: wishing that you could do sniffing is unrealistic
... you can't do it between text/plain and anything
... magic numbers are used in different places
... sniffing is intrinsically heuristic
... you might as well put the rules in the server
... the finding covers too many cases
... there are all sorts of metadata, content type, character sets etc
... might be better to focus on content type issue
... sniffing isn't a viable alternative to labelling
... it's not a matter of authoritative metadata, more cascading metadata
... different sources of information about what the type would be
... comments on the web sec, bug reports on the mime sniff living standard
... it's a complicated situation
... I don't think there'll be a simple solution
... to rescind it or sniff everywhere
<wycats__> I don't understand how anyone thinks we are going to have a spec that tells the HTML spec that it MUST NOT do something that it has to do to match reality
<wycats__> that's just absurd
noah: we have the reality we do with servers, I don't think it proves very much about what might have been improved in the beginning
annevk: in the beginning we didn't have Content-Type, we just had sniffing
<slightlyoff> how does this even matter?
<slightlyoff> we can't buy into Postel's law less
<Larry> slightlyoff: yes, you can
<Larry> x-content-type-options: nosniff "Solves" the problem
noah: this is water under the bridge though
... it's not really clear how many of the problems are because it's conceptually flawed
... or because it hasn't been implemented
... there are architectural reasons why follow-your-nose is important
<timbl> I much prefer the content-type, body pair model to the one in which all possible document contents are sniffed by one single interplanetary sniffing algorithm. Robin's proposal, that we have things like <plaintext> just begs the question, and moves the authoritative metadata moves to the next level.
<wycats__> timbl: I agree with that
<wycats__> timbl: I agree that in theory that is good, but we *must* accept that Postel's Law is the reality of the Internet
<wycats__> why mess with success?
<slightlyoff> timbl postel's law isn't a "nice to have"; only one half of it is
<slightlyoff> it's a description of what systems at scale INEVITABLY do
noah: it should be possible that as much as possible of the web can be understood by following pointers
... maybe we can refocus the finding
... surely no one thinks serving a PNG as image/jpeg is the right thing to do
... we don't know what people will do long term
... labelling things well is generally good practice in an architecture
<timbl> Postell's law is not th reality of HTML5
<wycats__> timbl: sure it is
<slightlyoff> timbl of course it is.
<wycats__> look at the parser?
<slightlyoff> timbl it's *actively* that
<wycats__> every branch that says "This is an Error" tells the parser what to do anyway
annevk: the community doesn't have the tools to follow this
noah: the tools will evolve
timbl: we can push the community, CORS for example
<Larry> The "nosniff" option is deployable
<annevk> there's nosniff content out there that you need to sniff
<annevk> because IE only implemented part of it
wycats: CORS isn't implemented widely because it requires sysadmin access
marcosc: even W3C doesn't do it properly
wycats: we could decide that Postel's law is an interesting curiosity, or an important thing on the internet
timbl: the HTML5 people say that you have to be liberal in what to send and liberal in what to expect
<Larry> annevk "need to" bears closer examination. You mean IE still sniffs "nosniff" content?
<slightlyoff> but that's not true about how behavior works
wycats: the spec says exactly what to do when there are errors
<annevk> Larry: yeah, e.g. image/jpeg vs image/png
<annevk> Larry: cause it all goes down the image decoder
noah: we need to push people to be conservative in what they send
... that's the other side of Postel's law
timbl: in Postel's law there's a huge space of messages that are not sent
... in HTML5, there is no difference in what you can send and what's accepted
wycats: HTML5 there's a set of documents which are valid and others
... the user agent can fail when there's an error
slightlyoff: if you look at the new parser for webkit, we have error functions which are noops
... in the real-world the software that has to continue to work
... in Postel's law, there's the motherhood and apple pie of publishers
... and the practical reality of massive scale with consumers
timbl: the current situation is that people are liberal in what they produce, and the browsers are liberal in what they accept
... that's why I said that Postel's law does not describe the current web
<wycats__> 1+
annevk: the guidelines are conservative/liberal
<slightlyoff> we saw this even in RSS
<wycats__> the whole point of Postel's Law is that the reality is liberal/liberal
<annevk> aaah
marcosc: maybe what darobin means to say is to rethink what it means to be conservative on the server end
... it can be sending content type or magic number or something else
<wycats__> it's telling people to be conservative, but if people LISTENED you wouldn't need the other half
<slightlyoff> timbl even in formats where errors should have been "fatal", we ended up with Postel's law dominating, and we got fixup-based parsers for those formats too
<annevk> hehe
noah: it says follow the specs
marcosc: we've been having discussion about magic numbers over last two years or so, for example with app cache and fonts
... people just couldn't use content-type, maybe there we can use magic numbers
... I'm saying there's other ways of being conservative
<noah> That can't be the point of it. Postels law says be conservative when sending. I accept that being liberal is where we've landed, but that is surely NOT what Postel intended.
<slightlyoff> why are we debating something that can't work in practice?
<wycats__> the point of Postel's law is that reality is always people sending liberally
<slightlyoff> i htought we cared about the architecture of the WEB
<wycats__> otherwise you can nuke the liberal half
<noah> What I think he wanted was to give receivers a little wiggle room to keep running while everyone cleaned things up, not to license long term nonconformance.
<slightlyoff> not a system that's web-like but not the web?
<wycats__> noah: definitely not
timbl: conservative means sticking to the spec
... all the groups are defining the protocol about how the web works
... I'd like to see the spec so that when I'm writing a server from scratch I know what to do, and one that isn't too complicated
marcosc: it's a real problem for me that I don't know how to label my new JSON format
timbl: label it
marcosc: I need to know whether to use a magic number or a mime type in a new binary format
... why should I bother if the browser doesn't care
annevk: the browser cares if you say it should care
wycats: what matters to me is documenting reality
<Zakim> Larry, you wanted to talk about recasting the language
Larry: it's helpful to stop talking about should I ever serve X as Y
... you have a body and a header and try to figure out how to interpret it
... it can be ambiguous about what it is
... it's possible to add the no sniffing option, but the browsers have to make it work
... once someone starts sniffing in a no-sniff context, everyone will stop doing it
... it has to be linked to an event, for example introduction of HTTP 2.0
... put the sniffer in the proxy, so you could serve it as no-sniff
... that would reduce a lot of the ambiguity
... absolutely true that if no one enforces it then content providers won't fix the content
<annevk> That'll hurt adoption of HTTP 2.0
<annevk> You don't want to close couple that
<wycats__> does anyone disagree with removing the MUST?
<slightlyoff> wycats__ I do not disagree with that
noah: we need to decide whether to take this beyond this discussion
... I don't think there's even a core of an emerging consensus
... it's possible that we should send people off to frame something that they think might lead to TAG consensus
... next thing up is setting TAG priorities
... is this something that people want to put time and energy to?
<slightlyoff> I'd like to propose that we not try to advise for things that are fundamentally incompatible with observable reality
<slightlyoff> I feel strongly that this cuts to the core of TAG credibility
<slightlyoff> and our current deficit in this regard.
wycats: I think the consensus that might be here that the TAG shouldn't have MUSTs when WGs can't implement those MUSTs
<Larry> if you're going to do something about sniffing, then work on the sniffing spec
<slightlyoff> I agree with rescinding it
<Larry> http://mimesniff.spec.whatwg.org/
<Larry> i think rescending it without replacing it is irresponsible
<slightlyoff> Larry that's one potential option; we can also explore others
<slightlyoff> Larry in what sense?
timbl: we could add a disclaimer in it
... sounds like HTML5 spec doesn't describe how browsers do all interpretation?
annevk: not quite everything, but it's fairly complete
<slightlyoff> what new space for error does it open that is currently not being explored?
timbl: we could say "this is the model", but see HTML5 for what actually happens in the browser
wycats: right now, there's a big list of things not to do, and I'd like to rescind that
<Larry> there's a question. we had an answer. if that answer is wrong, then what's the right answer
noah: we can't settle this here and now, I want to get two people to gather proposed solutions
... lead email & telcon discussion of pros and cons
<slightlyoff> didn't we just have that discussion?
noah: or we could discuss again on Wed
... get us to a place where we can do something useful
timbl: we're not all on the same page at the moment
... let's see if we can pursue on Wed
marcosc: could we have a breakout on Wed with a couple of us?
noah: do that at another time
<slightlyoff> +1 to that
wycats: my proposal is rescind current document & replace with something aspirational
<Marcosc> MC: +1
<slightlyoff> agree
<slightlyoff> +1
wycats: the current document doesn't reflect reality at all, so it's bad to leave it around
noah: let's pick it up Wed
... I'd like a couple of people who could frame the discussion in that way
<annevk> It could be like CSS1: http://www.w3.org/TR/CSS1/
timbl: I went through IETF and learned to be good about MUSTs and MAYs
... they've often tripped us up
... the IETF says you must use the word MUST when conforming specs must do it
... people read it as an ethical must
... which it isn't
... it just indicates that it's not a conforming implementation of the spec if it doesn't follow those
wycats: that means that browsers aren't conforming implementations
<slightlyoff> point of order: can we get a Google Calendar or something for our calls and agendas?
<wycats__> slightlyoff: yes please
noah: in this session I want to do three things: 1. set out goals for the meeting as a whole, 2. say a few things as chair, 3. schedule F2F
... main goals:
... look at what we want to do in next 1-2 years
... need to wrap up some of the existing work
... and figure out what we're doing, not just picking up random projects
... when in gear, we'll usually have 2-3 major projects
... with 2-3 people driving each effort
... want to work out which of the things we're talking about are likely to be these things
... next, want to establish shared understanding & working relationships
... next, want to pick the 2-3 things that we want to try
... not just random discussion, things that people are going to take forward
... with writing, telcons, bringing in community
... next, starting to review establish TAG positions that are controversial
... next agree to publish fragids
... next, decide directions on existing projects
... there are a few big ones (publishing & linking, httpRange-14)
... and a bunch of things that are more minor, many that are stale issues
... might look at them on Wed
annevk: can anyone sift through them?
noah: I'd like to but I have very limited time
... ---
... welcome new members, and thank you to outgoing members
... outgoing members should always feel welcome to come to meetings & social events
... this morning we looked at the charter & the mission statement
... that's the bounds of what to do
... my job is to organise the group and make sure we get results
... we're a small WG
... most others have people who are sent to solve a problem
... would like everyone to think about commitments you've made
... you signed up to about 25% of your time, and to come to F2F meetings
... there's no one to do the work but us
... we are very understanding about peoples' day jobs
... bursts of activity for 3-4 months
... but this stuff is hard, and people disagree about it, and it needs effort
... we have to impose people to do grunt stuff too
... including getting CVS sorted out, and scribing
... trying to be open to requests around topics
... but administrative changes are difficult
... try to try things the way we're doing it now
... hold of critiques for 3-6 months
... because it's hard for me
... on scribing: we try to be careful about privacy
... historically this is a close group, not unusual to hang out
... a lot gets sorted out over dinner etc
... project pages
... when we kick off a project, we try to create a project page that covers goals, success criteria, deliverables, people, issues/actions etc
... all drafts & pages like this should have a 'current version' and dated versions
... minutes refer to dated versions
noah: try to meet when Tim can be there, and me
... propose London meeting late May
... week of 27th
wycats: it's not trivial for me to schedule international travel with only a couple of months notice
... best 12 months out
timbl: sometimes urgent things come up
noah: we'll typically do 4-6 months
... so would pencil in September now too
RESOLUTION: TAG will meet in London 29th-31st May
annevk: what happens between May & October?
noah: there's lots of holiday, but we'll have telcons
booked Oct 13-15th
booked Jan 6-10th
http://www.w3.org/2001/tag/2013/03/18-agenda#ECMATC39
wycats: slightlyoff & I are both on TC39
... there are many things TC39 are doing to enhance JS semantics to provide more things that you could do with it
... there are 2 things I'd like W3C to do be doing
... 1. taking advantage of these better semantics
... eg defining getters & setters, proxies, modules
... W3C WGs should describe things in terms of TC39 JS
... less around ad-hoc ideas around host objects
... Chapter 8 in JS says user agents can do anything they want
... I'd like it if WGs would take advantage of new power of non-Chapter 8 parts of JS
... 2. there are things that TC39 that are in conflict with what's happened in W3C
... in particular around definition of web workers
... which is around adhoc definition of global object
... want to advise WGs to start thinking, to the extent that there are new semantics
... right now new browser APIs there are new objects on global object
... but there will be modules
timbl: are these like modules in node?
wycats: the syntax indicates imports etc without executing the code
timbl: it looks procedural but is declarative?
wycats: it's like an import
... import variable from module
... module name is a string
timbl: there's a search path?
wycats: there's a series of steps
... each has built-in descriptions and hooks
annevk: and it's all async?
<slightlyoff> yes, it's all async
wycats: yes
... W3C isn't paying a ton of attention to this
... it would be great if new APIs from W3C were defined in a module
... there's a lot of detail here
... slightlyoff & I would volunteer to detail these
... we'd like to have general direction to use these
timbl: needs to work in either situation
wycats: could just stick with global objects, but I think that would be a mistake
marcosc: host objects aren't defined in terms of ES6
... you're talking about layering on top of ES6
... we want to adjust WebIDL to use ES6 and define in WebIDL
<slightlyoff> this is a bug
<slightlyoff> webidl is a bug
wycats: there isn't anything in host objects which is incompatible in ES6
... in ES5 there are host objects, they don't exist in ES6
... there may well be obscure edge cases where you can't describe things in JS, but in general that's not the case
marcosc: we had modules in WebIDL we could translate into modules in ES6
... we had something where when you declare an object in WebIDL it ends up in global scope
... I don't think we're fundamentally breaking things
... I think your proposal is good, that we should align more
annevk: WGs and individuals aren't paying attention
marcosc: ES6 is in flux
... WebIDL had native brand to get at what the object type is
... that changed, the name of it changed
<annevk> (I'm paying some attention, but es-discuss is hard to follow and the drafts are PDFs with some force download flag...)
wycats: that's fair, I'm not saying rewrite everything right now in terms of ES6
... my point is we should start paying attention to it
marcosc: what can we do?
wycats: create guidance to WGs about how to think about this, in coordination with TC39
<Zakim> noah, you wanted to ask about balance between TAG and other wgs?
noah: how much of this is the TAG's job and how much is other WG's?
... try to defer to WGs when they exist & have responsibility unless they're screwing up architecturally
... why here & not Web Apps?
<slightlyoff> I do think they're screwing up big time
wycats: this is interoperability, working with other standards orgs
marcosc: we have public script coord mailing list
noah: just because we facilitate these things doesn't mean we own them
... we could still go to Web Apps and ask them to handle it
annevk: I think we could do this through Web Apps
... there's a ton of WGs but they listen to Web Apps
noah: they could also publish a Rec
annevk: we're chartered for that, and they're not
noah: APIs are generally in the Web Apps charter, aren't they?
annevk: no
<annevk> well APIs are
noah: should we schedule a tutorial on what's new in JS?
<Larry> https://speakerdeck.com/kitcambridge/es-6-the-refined-parts
<annevk> RECs on how to do APIs... dunno
timbl: I bet a bunch of W3Cers would be interested in that too
<annevk> could be I guess
noah: wycats, can you do it low notice? Wed?
<Larry> there was a video talk at W3CConf that was good
<Larry> Kit Cambridge ...
wycats: I could cover a lot of ground on Wed
Larry: there's a good video by Kit Cambridge on ES6
<timbl> timbl: It would be good then to sync with Amy who organizes project reviews
<Larry> http://www.w3.org/conf/2013sf/video.html
<Larry> has the video
<Marcosc> this is good too: https://dl.dropbox.com/u/3531958/es6-favorite-parts/index.html#/
noah: let's schedule 90 mins on Wed
... advertise that
<jar> http://lists.w3.org/Archives/Public/www-tag/2012Sep/0031.html
jar: sounds like you're talking about same thing as Doug was complaining about
... Doug sounded very frustrated
wycats: this is a targeted concern
... this is WebIDL doing something causing problems with TC39
annevk: XHR is defined as an object, exposed on window, not on prototype window
wycats: as far as TC39 is concerned, there is no prototype window
annevk: are you concerned about people defining things like methods on window or objects?
wycats: you avoid exposing things on window is that you have objects via module import
<slightlyoff> but you WILL have modules
annevk: how do you avoid doing what we do?
wycats: we fake it
marcosc: how stable is the modules proposal?
wycats: I'm not saying start doing modules right now, but that they start looking at it
... the syntax isn't stable
<annevk> slightlyoff: I'm not saying that, I'm saying that nobody is telling us what to do
timbl: how do serious websites deal with the transition?
wycats: there'll be those that rely on browsers that have modules, and those that don't
<annevk> slightlyoff: this is the first time I heard about this and maybe a bit from the TC39 echo chamber, but that never reaches us in clear terms :/
timbl: will people write things twice, or will they fake it?
<slightlyoff> transpilers
wycats: once module syntax is stabilised, they'll stop writing them node style, and start writing them module style
... using AMD semantics
... write nice declarative form in syntax
<slightlyoff> FWIW, we already have ES6-to-ES5 transpilers written in JS
noah: server-side adaptation for those browsers?
wycats: yes, that's already happening
slightlyoff: ECMAScript transpiler in the browser
... already happening
<noah> I think that was specifically an ECMAScript 6 -> ECMAScript 5 transpiler
slightlyoff: larger point is that WebIDL is today a barrier
... core mismatches in the types
... we should be educating people about new features
... put people in mindset of users when designing APIs in the first place
... webIDL doesn't help make it easy for users
... eg constructible objects with no constructors
... you can't get an instance of this type
... it will hand you alien objects you have no recourse for
... makes you think about types that aren't efficient to express in JS
... eg numbers that aren't floats
... leads you towards designs that aren't appropriate
... at Google, we work through example code ignoring formal description
... make that idiomatic
... work that back to its definition
... we could help people write idiomatic APIs
<Larry> need JSON schemas
<Larry> JSON isn't javascript
<Zakim> timbl, you wanted to ask whether webIDL is right for close Ecmascript integration
timbl: how JS-specific is WebIDL now?
... is it being enhanced with all the new things in JS?
... or is it language independent
marcosc: there's like attribute foo, it forces you to create a setter function
annevk: OMGIDL was language independent
... but didn't define a whole bunch of cases, didn't do constructors and stuff
timbl: can you use all the tricks in JS in WebIDL
<slightlyoff> we were successful in pulling WebIDL away from Java
<slightlyoff> which it used to be joined at the hip to
<slightlyoff> and there are left-over semantics from that era
<annevk> that's such a non-issue though
<slightlyoff> the mismatch is pretty large still
<annevk> that was basically heycam's hobby thing
<annevk> it didn't affect anything
<slightlyoff> annevk the legacy is driven all the way through the design
<slightlyoff> annevk it did, it introduced types that were JS native
<annevk> slightlyoff well yes the legacy is, there are dozens of specs and UAs written in terms of it
wycats: in ES there's internal spec facilities
... which you can overwrite
... webIDL makes extensive use of these facilities
... want them to use the proper facilities in ES6
... if we want to have a system that describes what JS objects are doing, we should describe them as something that a JS developer could write
slightlyoff: WebIDL drags you away from idiomatic JS
... doesn't teach you about how to design a JS API
annevk: until you have an alternative that works for spec writers, don't criticise WebIDL
slightlyoff: the advice is to design the API by example in JS
wycats: this is an important distinction
... currently it maps onto C++ implementation
... like int32s
<slightlyoff> it's not simple
timbl: I'm worried the flip side
... how would it do describing jQuery?
... with lots of overloading
marcosc: there's no problem with overloading
wycats: WebIDL is mapping onto low level semantics of implementation
... we want the spec device to map onto semantics of JS not C++
annevk: there's no disagreement
... there's just not enough people to write the specs
wycats: so we should make WebIDL better to use
<slightlyoff> Marcosc I'm afraid that's just wrong
marcosc: there's different things
wycats: it's meaningless to define something in WebIDL that can't be implemented in JS
annevk: you might want additional constraints
<slightlyoff> annevk wanting additonal constraints are the sort of thing that you should be considering without syntax
noah: history is from a corba-like view of the world, language-independent spec of APIs
... JS emerges as major implementation
wycats: no one wants language independence
noah: are we aiming for no WebIDL and just some JS-based spec?
annevk: WebIDL is a mapping
wycats: we're just proposing that if there's something like WebIDL, it should be described in terms of JS
slightlyoff: people who are not JS developers don't have a good guide about how to design JS APIs
... if you're used to C++ then you reach for WebIDL and use it
... and you get people building APIs that aren't suited for JS
... we could change WebIDL, or how we teach people to use it
... but let's talk about TypeScript or other options
<slightlyoff> yes, that's right...it's about how to think about the problem
timbl: sounds like it's the way of thinking issue that is the real problem
... the jQuery pattern of overloading, things like passing around functions
... these aren't like C++ at all
... is there a lot of lossage at the more functional, JS end of the scale
<slightlyoff> yes, we loose a lot of that sort of flexibility in DOM APIs
wycats: if you're a C++ programmer, you won't be writing idiomatic JS
<slightlyoff> yes, there's a culture of failure around this
annevk: people are copy&pasting the patterns from previous specs
<Larry> news from last week: IETF is spinning up a JSON working group
<Larry> IETF is doing other JSON work. Including schema for JSON
<Zakim> Larry, you wanted to ask about WebIDL & JSON schemas
Larry: IETF are working on JSON, maybe a schema language
... DP70, talking about when to use XML
... think it should be extended to talk about XML & JSON
... bringing this up because JSON schema talks about defining value types
... seem to have a relationship with webIDL
... if talking to TC39, consider role of JSON
... it's language independent
<noah2> http://tools.ietf.org/html//bcp70
annevk: it doesn't have methods
wycats: seems unrelated
timbl: if you define a method, you give types of parameters
... if you have a complex structured parameter, such as a dictionary
... or a list whose values are of a particular type
... then quite a lot of the work in defining the interface to the method is defining the complex parameter
... and describing that is the same as a JSON schema problem
Larry: the datatypes that are available in WebIDL are basically those available in JSON schema
timbl: can you say that in WebIDL
wycats: yes, WebIDL's problem is not lack of expressive power
... they just create crazy JS semantics
Larry: my point is under general topic of coordination with TC39, you've identified one issue, about WebIDL
... while you're thinking about that, interaction with JSON is also important
... tried to get them to update charter to include coordination with TC39 & WHATWG & W3C
... W3C needs to be engaged in JSON update also
wycats: if it's only a problem with finding people to write a strawman, we can work with that
annevk: TC39 need to give guidelines to the people doing DOM stuff
... there's just a lack of communication and lack of guidelines
... feels more like a shouting match
... we're just trying to solve a problem, and we're input constrained
... all we get is "you're doing it wrong" with no concrete alternative
<slightlyoff> well, I am doing that
<slightlyoff> on a weekly bais to API authors here
<slightlyoff> right, nobody's assuming malice
wycats: sounds like slightlyoff & I need to go back to TC39 to get communication working better
noah: what would you like the TAG to support you to do?
wycats: I'd like to go back to TC39 to get resource on working on successor to WebIDL
noah: I don't know if we have a group to do something with it
<Larry> script-coord mailing list is still active
JeniT: When I did the work on the task force of the HTML and Data stuff, it worked pretty well. So, maybe we say there should be a task force.
slightlyoff: I've spent a lot of time working with people who are trying to come up with APIs which are better
... people don't have experience, haven't got a guide about how to build an idiomatic DOM API
... we could create those guidelines, talk to TC39 about it
wycats: I like Jeni's proposal to put together a small, focused task force
noah: when we did that, we had a better understanding of what the issues were, as the TAG
... if we could float these ideas on the TAG mailing list and other lists
... say that we're considering task force or outreach to TC39
... see what pushback we get
annevk: Mozilla has invested effort in transitioning from old bindings to WebIDL bindings
... the right things happen
<slightlyoff> we have a bunch of perl scripts ;-)
wycats: that means there's a constraint to be compatible with that tooling
annevk: API specs are built around ReSpec which has native support for WebIDL
<slightlyoff> I'd once again like to suggest that we can help people design better APIs without changing the tooling; we can push on both
<slightlyoff> and they can happen in parallel
noah: are you saying we should therefore go slow?
annevk: short-term, having better advice would be awesome, especially backed by TC39
... then we can see whether people disagree
noah: how does TC39 work? how would we engage with them?
wycats: most of the work that gets done is done by champions
... committee is 20-25 people, once every 2 months F2F meeting
... chair but he's not like you (noah)
noah: should we get onto their agenda for a meeting?
wycats: slightlyoff or I would become champions within the group
noah: I'm nervous that we're just starting on this, not sure we can make an informed decision
slightlyoff: that's reasonable: we can look at design issues for example
annevk: we can say we're interested in TC39's opinion
noah: I need to know what the TAG needs to know
... draft of an email to TC39, on our private list, then sent on behalf of TAG
... vote on that on a telcon, to send email on our behalf
wycats: annevk's suggestion is good, just go back say that there's interest
... in getting TC39's opinion about good JS API design
noah: let's draft a resolution for the minutes that you can point at
... use private list for drafts that we haven't yet agreed on as the TAG
... usually better if this ends up in a specific WG
annevk: I think that's Web Apps
wycats: I think that TC39 should do it with people in charge of WebIDL
... but perhaps there aren't those people or they don't have bandwidth
annevk: Cameron McCormack is driver of WebIDL
wycats: TC39 have lots of skilled resources who might be interested in working on this
... a TF that has lots of people who don't have bandwidth isn't going to work
<slightlyoff> the last time heycam was at a TC39 meeting, IIRC, was nearly 2 years ago
<slightlyoff> and we got good prototype linearization done
<slightlyoff> but that was a long time ago