See also: IRC log
<Marcos> we look at stream and file API
<Marcos> Need to look at what we do with DOM 3 API at 10am
<Marcos> People who are important are Jakob and Doug, but there is time conflict
<Marcos> So we will do it at 11:30 (DOM3 Events)
<Marcos> Testing we also need to discuss
<Marcos> We need Jonas for the File API
<Marcos> Afternoon: index DB and XBL2 and component model, in the afternoon
<Marcos> Bryan wanted to add an item: Event source extension for connectionless push
<Marcos> If we get through stuff quickly, we can start talking about API design
<Marcos> Stream and file API, we can start off with that
<Marcos> Scribe: Marcosc
<Marcos> EU: I want to discuss file saver
<Marcos> Not all the use cases are covered by download attribute on the a element.
<Marcos> ee: we had talked about looking at saving a blob VS saving a URL (the resource)
<Marcos> ee: is there interest in implementing this?
<Marcos> JS: yes
<Marcos> CMN: nods in agreement
<Marcos> AB: We wanted to replicate the same expirience you get form downloading a link. We have implemented two APIs that get sent a blob and the browser displays a dialog and simulates downloading a file (but using a blob). The idea is to make the user experience is the same.
<Marcos> JS: how is that different from file saver
<Marcos> AB: you don't get the progress events.
<Marcos> AB: going to paste in a URL
<Marcos> If you look at the second page… replicating content disposition: which shows the save dialog
<Marcos> CMN: is there any indicator when the download is done.
<Marcos> AB: no. it works like the current save dialog that browsers use
<Marcos> CMN: We have the File API right now. And I think that is what we want before a full filesystem API. Our use cases are "real file system access": create directories, get at files, so the user can share files with Apps.
<Marcos> AB: we are not opposed to such an API. But they are not a high priority for us (MS) right now.
<chaals> [berjob waltzes in already...]
<Marcos> AB: this is something we did instead of file saver… the file system API is further down the road.
<Marcos> EU: how is this different from the current API?
<Marcos> AB: we don't support the download attribute. We don't to support navigation to a blob URL. So if the blog points to a URL page, we don't want to display that page. we are concerned about scripts running in the page contained by the page.
<Marcos> RB: could you not always download it? just a suggestion?
<Marcos> AB: maybe :)
<Marcos> EU: not sure what Chrome does right now. We might be displaying it in an iframe. But we are not sure about the origin right now and what privileges it has
<Marcos> AB: for use, we have abstract protocol handler…
<Marcos> EU: It sounds like we have 3 different things that overlap.
<Marcos> JS: I'm very interested in supporting the use cases, but 3 different ways is not good. I would like to find a way to avoid having 3 different APIs
<Marcos> JS: file saver could do everything you want
<Marcos> EU: it doesnt have a clean way to allow the user to open the file
<Marcos> JS: but it is fully API driven
<Marcos> JS: it would be nice to find a single way. So it would be nice to figure out what the requirements are consolidate them
<Marcos> AB: agree… we don't want to implement multiple API
<Marcos> CMN: its clear that we all want to support the use case…. and we don't want to tell devs how to use multiple APIs
<Marcos> AB: Can we talk about file API first
<Marcos> before moving on to stream
<Marcos> In the first page of the first page: readAsBinaryString… is there a strong use case for it? is that for legacy reasons?
<Marcos> JS: It is. But it's ok to drop it
<Marcos> AB: We would like to see it removed
<Marcos> JS: it's more legacy, so I'm ok with dropping it
<Marcos> MC: Second question: do we really need the restrictions on the URL?
<Marcos> JS: I have not looked at the URL part
<Marcos> Arun has been working on it. But he would probably be interested in discussing it further
<Marcos> AB: the third thing is a suggestion: a really common pattern is to have an URL that represents something (e.g., an image). So one of the things that we have implemented is boolean flag, that creates a one time URL. The first time it gets dereferenced, it loads and it goes away
<Marcos> AB: final question, I'm wondering if it's ever possible to see the protocol version that is dereferenced in from the blob URL
<Marcos> AB: we proposed it's not necessary
<Marcos> JS: agree, but Arun should have a look
<Marcos> JS: another proposal is to drop BlobBuilder in favour of a contructor
<Marcos> when we started working on the blob API, a req was to have a blob whose size was unknown (a steam).
<Marcos> AB: feedback we got was don't make it blob, make it something else… so it's how we ended up with at stream… so we have a Stream Reader, which allows you to covert to a blob. We make the stream available at ready state 3, instead of 4. It allows people to view media before the whole thing finishes
<Marcos> E.g. in a mail app, you can start viewing stuff at readystate 3, and start showing it without waiting for the end… and start processing data as it downloads … use chuck upload as well
<Marcos> CMN: we have similar use cases
<Marcos> JS: so can you create streams?
<Marcos> AB: yes, we have a stream builder.
<Marcos> JS: it should interesting
<Marcos> JS: we had a contributor who did something similar, but what he did was as it progresses, but they grow incrementally until you get the blob that has the whole file… the blobs have a fixed size, so it just keeps growing… you always get unique blobs.
<Marcos> EU: AB's proposal it sounds interesting to me
<Marcos> EU: is we have a stream object that we can convert to a blob would be good, so we can hand it to file writer
<euhrhane> [not necessarily convert to blob--possibly we'd just pass the stream to the FileWriter.
<Marcos> KK: we need a more consistent way to do tests… and we don't have an approval process
<Marcos> KK: my experience has been that when people start looking at tests they start finding issues. An approval process might help.
<chaals> MC: It is difficult to approve tests where we auto-generate a ton of them. You can produce lots from WebIDL, and it is time-consuming to check each one.
<chaals> ... might be a good idea to look at a test generator, rather than the test.
<Marcos> KK: the tests I have seen have not been autogenerated.
<Marcos> KK: maybe we can create task force, somewhere more focused to discuss testing
<Marcos> CMN: not sure how we would do this
<Marcos> CMN: our experience is that people who make tests are usually not spec people
<Marcos> Wilhelm … introduces himself
<Marcos> wilhelm: we had a meeting last thursday about testing… we need to make the tests simple, it would be good to have a standard…. we propose using testharnes.js (HTML5 WG is using it). have a look at test.w3.org. There are lots of tests there that use the test harness, so everyone can see how its done. We need someone to nag browser makers to get tests so we don't duplicate work.
<Marcos> CMN: So, do we need a sub group? wilhelm, how should we collaborate between Webapps and the Testing and Tools group.
<Marcos> wilhelm: please contact us. For visual things, use ref-tests from the CSS working group. We are happy to collaborate and provide guidance.
<Marcos> CMN: but which group should we do it in?
<Marcos> jG: there is already a mailing list. public-webapps-test-suite ?
<Marcos> wilhelm: lets figure out what tests there are already
<Marcos> wilhelm: then we can see what tests are available
<Marcos> KK: it think getting a good rhythm going… want to try something a little different. If we just do the list, that is ok. But we need some more active ways to do things… getting people to talk more.
<Marcos> JS: some feedback we had a while ago, it was harder to write tests than necessary. Because of the infrastructure, it made tests hard to write tests. W3C tests required more boilerplate than at Moz.
<Marcos> JS: at mozilla, we end up doing it our own way to because its easier and faster
<Marcos> JG: yes, there is a bit more work involved with the W3C tests.
<Marcos> +q marcos
<Marcos> JS: the number of tests you get is affected by how easy to write the tests
<Marcos> JG: I've had a different experience
<chaals> CM: How does HTML test group work cmpared to not having one?
<chaals> JG: Well...
<chaals> KK: Yes
<chaals> MC: having tests be very easily accessible with an interface is really helpful - especially when linked to the spec.
<krisk> HTML started a taskforce two years ago
<krisk> Before that their was no html5 tests
<Marcos> CMN: my experience is the same similar to JG and JS… when you pay people, you get people making good tests. But also making them easier to write for volunteers, also helps. As KK suggested, we need review.
<Marcos> CMN: it seems like it's an action on the chair
<krisk> today we have a large number of tests across a number of features that are implemented in browsers today
<Marcos> wilhelm: writing a good test suite is as hard writing a spec. We should have a dedicated person to write a test suite (equal to the editor).
<Marcos> CMN: how many person think there should be a dedicated testing person for a spec?
<Marcos> [plenty of agreement]
<Marcos> MC: we could make it a requirement that no spec start without also having dedicated tester
<Marcos> CM: not every org has dedicated spec people.
<chaals> MC: It is fundamental to have tests, so you can't seperate without being able to get a test suite.
<Marcos> JG: this person does not need to write the tests… the person would have the responsibility to source the tests.
<Marcos> JG: it does not mean that only one person would write all the tests (if any)
<Marcos> wilhelm: if you have 15 specs, you can break up the task amongst multiple people
<Marcos> CM: does it have to be a different person than the editor?
<Marcos> RN: when do you need to involve a testing person?
<Marcos> … discussion… identifying them from the start
<Marcos> DS: that has traditionally been the role of the editor
<chaals> RN: What's the diffrence?
<chaals> MC: It can alleviate the load of the editor
<chaals> ... we need to discuss what to do when you generate tests and then the spec changes - how do you avoid starting too early or too late
<Marcos> RN: but we still not clear when we should have tests
<Marcos> DS: for DOM 3, I've requested that people contribute tests… but didn't get much back
<Marcos> DS: I would like to have a req that before a spec progresses to CR, it should have a test suite
<Marcos> CMN: it seems reasonable as a first step to appoint someone for testing.
<Marcos> RESOLUTION: We will insist that when work on a new spec, a person be appointed to handle testing
<Marcos> KK: as DS said, we should have something in the process so specs can't move to CR without a test suite
<Marcos> DS: part of LC would benefit from a test suite.
<Marcos> CMN: problem is that it is expensive to produce tests… so, we don't want a process heavy way of making tests…
<Marcos> JG: Tests really only come out when people are implementing stuff
<Marcos> JG: implementers who want to have a bug free implementation are going to produce tests
<Marcos> CMN: another group to get test from is non-browser vendors (e.g., content providers)/.… how do we talk to those people?
<Marcos> JG and JS say there are a few examples of people who have done it…
<Marcos> KK: happy help to set up guidelines
<Marcos> DS: if we have a good way to contribute tests, that would help
<ArtB> WebApps' Test Submission process: http://www.w3.org/2008/webapps/wiki/Submission
<Marcos> BS: one of the best ways to learn is by doing. We need really good guidelines, so test examples are good. Looking to service providers and universities to help use build tests would be good… it benefits lots the whole community.
<Marcos> CMN: the public tests can vary in quality
<Marcos> Israel: when is the right point to do testing?
<Marcos> JS: I don't care what the tests are and what they are targeting, as long as we get lots of good tests
<Marcos> JG: it's never too early
<Marcos> MC: I agree
<Marcos> DS: who is going to enforce this policy?
<Marcos> CMN: good will :)
<Marcos> CMN: there is no formal policy that we can enforce
<Zakim> Josh_Soref, you wanted to say you're either implementing or using someone's implementation or planning to use it
<Marcos> JS: hopefully you are implementing this feature… people have a vested interest in the spec and hence produce tests
<Marcos> ACTION: Art and Charles to make a proposal about how to appoint a person to be assigned for testing for a spec. [recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action01]
<trackbot> Created ACTION-637 - And Charles to make a proposal about how to appoint a person to be assigned for testing for a spec. [on Arthur Barstow - due 2011-11-08].
<inserted> Scribe: Chaals
MC: we're getting frustrated
trying to write APIs because a lot of stuff coming out we don't
necessrily understand the design patterns - or when WAC brings
in an API it doesn't look like a Web API and they lose out on
... so we ae trying to reduce the "not invented here" thing by being able to get in APIs that match what we think of.
... so we are lookig to create general guidance (rather than formal requirements) - what WebIDL gives you, how do you describe throwing an excepetion and what does that mean, etc.
... It's a friendly list for editors to find information that is helpful.
... The ideas have all been under development, and effectively black magic in people's heads that wasn't available to others.
... Would also encourage people working on frameworks to help us work out how we can make things more easily.
RB: To avoid making this exess make-work, when you understand something about a design pattern you haven't thought of, just drop in a rough email. Don't bother trying to get it right and perfect, dump the half idea and let Marcos and me figure out how to explain.
[throwing exceptions, defining events, how to use dictionaries, etc]
BS: Would like to have had a
discussion not just about JS/DOM APIs, but also other things
happening here like things on abstract resources handled by the
... We see a number of patterns - trying to understand the rationales for that is important.
<bryan> Here is the link to the draft presentation I had prepared for the TPAC discussion on this topic. It captures some of the questions we had and the objectives for a discussion: http://bkaj.net/w3c/TPAC-2011-API-Design-Patterns.html
BS: why is video a tag, why is event-source an API, etc.
AR: Trying to understand if the intent is to capture the way things are done, or what we think would be an ideal design pattern.
MC: We are trying to figure it out too...
RB: A large element is a cookbook. Editors do something, someone says it is a bad way, they don't wnderstand why and just want to make something that works. Goal is to make editing easier
CMN: I'd find the historical
... What's the future of this? A note, what?
AR: If we write down what people do now we perpetuate it and that is bad.
MC: We propose this as a note - a
useful thing for the community.
... we are trying to help consistency.
AR: Consistency is good.
CM: Helping editors construct
prose and interfaces to match what other people are doing is
good. I agree also that it is good to document the
... it isn't just a matter of people agreeing, because there are real disagreements right now.
MC: Yes, we don't just want to codify what people are doing now, because we don't want to describe how to do things wrong...
AR: The point isn't to make a normative requirement set, right?
CM: We don't have a general place to do this at the moment...
RB: THere are a lot of people who are here??
Travis_MSFT: Is this less about general API design and more about particular things that you want to do - events or callback? what is a webby error? ...
[examples of different approaches]
scribe: Not sure a document can recommend aright way, but might describe a possible set of ways to do so.
MC: Ca Can show examples, and why they did it.
JS: Think this is a great idea.
I'd like to know e.g. how you should write a callback-based
approach and why. I'd love to have more input from people who
... in particular, from more than two people who do the same thing already. Take into account beginners, who are not here.
... most important peopl to get input from are not in the room
RB: E.g. JQuery standards group
JS: Right. We should talk to those guys.
AR: I can tell you what to do ;)
Balaji: Good examples are important. We should do this across different WGs. ANd there are different groups that have very fdifferent patterns, e.g. geolocation.
RB: Yes. People outside this WG don't know or care about working group boundaries.
<nvbalaji> Not suresh. I am nvbalaji (nvbalaji)
CMN: I think the TAG has a role here - at least in the structure. I don't think we want to palm this off to the TAG, but I think they have a role as custodians of these large questions.
NM: I don't think TAG has "the
expertise" here, and we don't want to repeat other people's
work. We don't necessarily have an opinion here, but we are
intersted in how these questions are resolved in different
... THere are things that are deep architectural things. When you have APIs, over time, you want to evolve things - and you can't install a flag day on the web.
MC: You were involved in the "architecture of the Web document" - are there relevant lessons from communicating, the experience of doing it, etc?
NM: Web arch is different to
architecture documents I have seen. Architecture documents in
IBM answered specific questions to say "did you do this right
or not?" Web Arch is more infromal - and is a retrospective
document, not prescriptive. Tim wrote design notes for the web,
which found their way into Web Arch (specific "thoughts")
... I think good architecture can be related to use cases.
... Invent good stuff, think about the use cases, think about architecture. but the web arch document is very backwards-focused - what was important in a running system.
DS: +1 to this - it costs a lot of time and frustration for people to do APIs wrong without knowing where they are going. We shouldn't reinforce anti-patterns, but ahving a document that says why they are anti-patterns and what other patterns could be used is useful.
BS: What I get out of this is "yeah, we need this discussion..."
[kibbitzing on list choice]
<ArtB> Scribe: ArtB
JR: IE9 implemented 100% of the spec
… think other browsers implemented about ~60% of D3E
CM: so, I think the Editors are OK with making the requested changes
… is that a fair characterization?
Sam: other than IE, who will implement this?
JR: Olli Pettay has been
... I don't know about Google
JS: I talked to Olli
… we intentionally remvoved ExceptionEvent
<heycam> [There may be confusion in the minutes at some points between CM and CMN. :)]
… Olli is not as concerned about edglazkove cases AvK and Ojan mentioned
… We do implement a lot of the spec
… Not sure if we will implement all of it
… and the parts we may not implement are features that matter
DS: D3E is a subset of DOM4 re the events
… we changed the spec to not have conflicts with DOM4
[ scribe missed James's comments ]
<gsnedders> Subset of DOM4? I thought it was a superset, containing additional things like ExceptionEvent.
Ojan: re Sam's question
<jgraham> Have we considered dropping the parts of D3E that overlap with DOM4?
… I can't give an official Google positin
<anne> gsnedders, mismatch, if you will
… but there are parts we would implement and some parts we won't
Sam: specifics please
Ojan: there would be a long list
… text input event has an input method
… I don't think WK will implement it
… key and char properties
… are problematic
… but we havent done a detailed analysis
Doug: please send that to the list
Jonas: re taking D3E stuff out of DOM4
… Ojan's list doesn't help with that
Ojan: I expect WK to implement DOM4
Jonas: for the parts that are the same, it doesn't matter
… I talked to Olli and my position is the concern is about the long time for DOM4 to ship
<gsnedders> Only if they are word-for-word the same, otherwise there might be accidental differences.
… it keeps adding features
Anne: we are removing features
… only event constructors are new
Jonas: what about mutation?
Anne: not there yet
… but they could be
Jonas: concerned about a continuously evolving spec that never finishes
… we need to ship something
… and D3E is done
… My concern is no clear signs of DOM4 actually shipping
… I think we can ship D3E sooner
Marcos: I don't agree
… think DOM4 is in good shape
CM: as Chair, we have a responsibility to ship specs
… I realize some people don't agree with that
… but that belief is not aligned with the WG
… by shipping I mean publishing a Recommendation
… Re Jonas' comments, we need to ship a spec
<gsnedders> One option for mutations events is surely to make them a module of their own?
… don't want a bunch of nit picks
<gsnedders> In which case DOM4 is more-or-less done
… that keep coming in
… think the spec is good
<gsnedders> (in terms of getting to a point where LC is possible)
… We could cut stuff out
… by reading the tea leaves of DOM4
… and if DOM4 changes, we can rev D3E
… I don't want to keep going in circles
… that costs lots of time and money for everyone
… for Editors and Implemeters
Doug: the parts under contention are from original DOM specs
… D2E is too old
… If DOM4 parts are better and stable
… and reconcile the 2 specs
… We could drop stuff from D3E if problematic
… and then go to LC
… I am willing to change spec to follow DOM4 where it matches implementations
… I can see AvK's approach is useful
… and successful
… so now we change D3E to match
… I still contend a D3E REC is useful
RN: is it possible to drop those parts not implemented or are controversial?
DS: yes, that can happen in CR
… that's kinda' expected
CM: need to agree on what's controversial and what's not
… and that requires drawing a line in the sand
… need browser vendors and others to define what's controversial
… We need to make a decision
… DOM4 is trying to make the situation better
… but we also have people that need to ship product now
… and of course we have the users of the APIs to consider
<gsnedders> One option is to proceed to CR, and see what parts meet the CR exit critera, and move from there.
… How important is it to ship a REC?
… Need to define the features as implemented today
Jonas: I don't want to have anything in D3E that DOM4 deprecates
… need to look at EventException
Jacob: I agree re deprecation
… I think we want to move fwd with constructors
… think we need to talk to talk about specific events
… and we can deprecate some events
… We should make sure the two specs are synch'ed
RN: can we drop the IDL interfaces?
CM: we agreed yesterday that WebIDL will be used
Jacob: need to work together to get a list of incompatibilites
… then we fix them
… then we we go back to LC
… There is a lot of feedback since D2Events
… If there are change requests, must open a Bug with Bugzilla
CM: let's ask Anne if he can help with this?
CM: so Jacob made a proposal?
… Who supports this proposal?
… 15 people supported the proposal
… Does anyone object to that proposal?
… there were NO objections
<Ms2ger> smaug, such as? Apart from the new exceptions, we only really have legacy stuff and some things from HTML
<smaug> Ms2ger: many parameters are optional
<smaug> DOM range isn't backwards compatible etc
<smaug> Ms2ger: I agree the changes are usually good
<Ms2ger> Mm, I guess you can say that
<Josh_Soref> Scribe: Josh_Soref
<Ms2ger> No calling in today?
<jgraham> I think it is possible to set that up if you want
<smaug> what is the topic?
<jgraham> Although the evidence is that you don't really exist
<scribe> Scribe: Josh_Soref
<anne> how many engineers does it take to dial a number?
<anne> 0, you just ask the hotel staff
... we have a proposal for Component Model
... and there's a belief that there's overlap with XBL2
... we'd like to understand the WebApp's community view on the landscape
... and we'd rather have an either-or and not an and
... I'd like to get a sense of the current implementers' view on XBL2
weinig: Sam, Apple
... we've discussed this a bunch of times
... Apple's iggest concern is the lack of a well formed declaritive model
... it's also a bit disingenous
... to say XBL2 is dead long live component model
... and then to say it's similar and has overlapping goals
AlexRussel: we assume them to be
... and our view is that they are
... the lack of a declarative model that's fully specified
... is something that we've taken as something
... and we'll work on
... Parser Integration, Shadow DOM,
... what we'll do with behavioral pattern
anne: We'd like Cross
... for things like Like / +1 buttons
... I don't think the goals of cross-origin and bindings
... are compatible
weinig: I think it's valuale to
have a component technology for the web
... XBL2 and the new proposals are both two different directions
weinig: otoh the framing of
... is XXX
... otoh the new proposals are fragmentary, not specified in sufficient detail
... and i'm not convinced they're in the right direction
... i need to see something that looks good, and currently neither looks totally right
sicking: my view is that
something between xbl2 and component model is the right
... i think taking xbl2 and using it and cutting things out is more in the right direction
... than the proposal i've seen from you guys
... it's hard to see too strong of a comment given the lack of a proposal for the declarative model
... even though xbl2 has a lot of complexity
[ Scribe reports that smaug agrees with sicking ]
weinig: i also agree with sicking
dg: I disagree
... because if we do it, we'll end up with a completely different spec
... if we cut things out, we'll have to reinvent the parsing
... we'll have to deal with event forwarding
sicking: i disagree, event forwarding is needed
dglazkov: event forwarding/event
retargeting are different things
... the general approach of the component model
... is that you subclass
... shadow DOM is something you get
... i do not think it's a good idea to treeat the component model is just a single spec
... because the different pieces can stand on their own
scribe: we already have two
... confinement is a problem outside of components
... you want to run scripts confined, instead of just in iframes
scribe: that said, i think it
would be a useful exercise for those who believe we should keep
... to go over it and see if it's doable
scribe: if they could go over it tomorrow for 30 minutes
sicking: to make actual decisions
which we're not at that stage
... we need more concrete proposals
... to have discussions here/now
scribe: we'll need actual
proposals to make
dglazkov: what's the right forum and what's the best format
sicking: brainstorming session if
we get the right people
... if we get the apple people, and hixie
[ hixie is behind you ]
sicking: and start sort of drafting some vague proposals
mjs: i like seeing
... two things, about evaluating them
... often it's really hard to evaluate things independently
... without evaluating the whole system design
... whlie people doing the core design work may have thhe whole thing in their head in a vauge whay
... second thing is it's important to have proposals drilling out in a detailed way
... but when you lay out the full details, you see problems that become very complex to address
... and it's hard to give a full review of a relatively high level sketch
[ bridge dialing ]
dglazkov: we have a
... it provides a very good overview
... it tries to capture the big picture
... i have gone over a small part of it at our powwow at mozilla all hands
... but i didn't go over the whole thing
... as far as details, i agree, details are hard
... i welcome ideas
... ewe tend to work on this in person.
... it brings certain isolation as most of us are working for the same company
... even posting things in public is not enough
dglazkov: and it turns out everyone is busy
dcooney: i agree with
... there was a complaint that proposals so far don't have a detailed declarative syntax
... and we'll address that.
... i'd like to encourage people to avoid taking some simplistic view
... that declarative and XXX need to be mirrored.
AlexRussel: there is, there's the form element v. xmlhttprequest
dcooney: some things just won't be expressable in both
weinig: i certainly can
understand not jumping to conclusions about individual
... when we saw the demos of what would currently exist.
... it seems that it was working around things with hacks without a declarative syntax.
AlexRussel: setting this up as an
either or is misleading
... our goal was to design declarative as a sugar on op of imperative
... at least a strong mirroring.
... can you define declarative with the imperative api?
[ no ]
sicking: this is what i disagree
... we want to have bindings adding to css that are purely stylistic
... things with a different security model that are cross origin
AlexRussel: if you don't have the
... if you can only do it declaratively
... you should do the archeology work to uncover the primitives and expose the,m
sicking: would you say style sheets are declarative sugar on the style attribute
AlexRussel: i don't think that's
the right question
... they have a different semantic in terms of inheritance
... for bindings in xbl2
... what you're missing is a way to be tied into the application life cycle
... treating style attributes as desugaring
... there's a missing bit of infrastructure
... it's the mechanism in which you're allowed to do i
travis: Travis, Microsoft
... i'd like to +1 the desire to move forward on specing on some balances of company's ideas
... there's clearly value in dspecing out ideas outside of the ocmponent model.
... i'm interested in seeing that move forward even without a declaritive model.
darobin: if there were a brainstorm model,. would you be interested?
mjs: in practice, the
declariative/imperative model, which will be the primary
interface for developers?
... for people believe in declarative, the approach to design is based on that
... define that first
<adrianba> s/of company's/of Alex and company's/
mjs: for people in imparative,
the approach design's that first
... and make a sugar layer for a subset of the other
... that's the underliying phiulosophical difference
... hopefully once we have specs for this, we can comment on this
... instead of hypothetical "i think this won't work""
... you can't predict if the layering will work unles you can see oth layers
dglazkov: it sounds like there
will be a brainstorm tomorrow
... we have some proposals for declaraitve syntax
... if you enjoy half cooked meals
... we're tready to sreve them to you
... the problem is difficult
... what made xbl2 so difficult to spec and comprehend was the decorator concept
... the fact that you could ad and remove behaviors dynamically
... i believe this is where we'll fall into despair tomorrow
... i recommend defering that question
dglazkov: there is a page where i outline th edifference between the two:
[ bad sequence, lag ]
dglazkov: subclassing is a very
common thing that happens in many languages
... you add behaviors to a thing by extending it
... decorator is clsoer to an aspect oriented language
... you can create xxx
dglazkov: component model tackles
element behavior attachment
... and defers decorators
darobin: i'm hearing agreement on seeing more specs and on a breakout/brainstorming tomorrow
dglazkov: all day tomorrow?
darobin: there's no one form w3c
... either it's outside the structure tomorrow
... you take a table and work it out
<heycam> Current schedule for the sessions tomorrow: http://www.w3.org/wiki/TPAC2011#Session_Grid
darobin: or you go through
channels tomorrow morning and propose
... we're enjoying the fact there's no team contact
[ people discuss the grid ]
heycam: i'd like to go to api
... could we have it at 1:30pm?
[ 1:30pm ]
[ poll, who might show up? ]
darobin: about a dozen people
mjs: i can't be here tomorrow, sorry
darobin: anything else? sXBL?
dglazkov: are we still considering sXBL?
darobin: there's a point wrt Rechartering
mjs: i think everyone has agreed
we want to do components
... and the disagreement about the starting point
... as long as the charter doesn't identify the name
darobin: chaals we should ensure the Charter doesn't name the spec
[ People leave ]
<smaug> is there some kind agenda online?
sicking: it's been almost
finished for 6 months
... anyone from Google here to talk about this?
... the only issue i know outstanding is error handling
... i don't know if we have filed bugs
... i can look tat u[p
... those might be more editorial
Israel: Israel from Microsoft
sicking: there's not all editorial, but the ones i see are really small
michaeln: Michael N, Google
sicking: Israel and I talked a
bit about it over lunch
... it seem s we might have agreement
... that error events aren't actually fired
... There are two types of errors
... one associated with a request
... one isn't
Israel: and one of those kinds is basically fatal
sicking: and we never arget ererors at the transaction
Israel: hopefully developers understand what they can do
sicking: that's actually drafted
in the spec
... we should clarify that we're talking about that in this thread
... and confirm people are ok w/ that solution
... beyond that, we could go through the buglist
... it's pretty simple stuff -13 bugs
darobin: anything we can close is good
sicking: i suspect most require
changes to the spec
... but we can coe to agreement
... bug 14199
... just a bug in the spec
... bug 14201
... - mention of version change request, which is renamed - trivial change
darobin: that's editorial
... bug 14318
... - that's important to mozilla
... bug 14352
... - idl marking requirement
... bug 14384
... - that's an interesting quetion
... currently we throw if readystate isn't done if you try to get result
... so you can't get the transaction during upgradeneeded, which is bad
... - we should set readystate to done
... - not sure if that's the right fix
... we could do something special in this case
... it's the request from an open call
Israel: there is a transaction, locking the whole database
... what should ready state be?
<scribe> ... done even though we haven't opened?
Israel: done seems fine
sicking: bug 14389
... - i wanted alex here
... we have two callbacks in the spec in the sync api
... the two way sfor creating a transaction
... currently they're [functiononly]
... so you can't pass an object with a handleevent or similar
... i have no opinion on that
[ jonas explains to alex who just returned to the room ]
sicking: is there value in supporting passing objects?
alexrussel: the object passing
protocol is strange from a design perspective
... you could have an object that handles lots of things
... the question from hj is "what's this?"
darobin: that's the benefit of using an Object
alexrussel: I think passing an object whose members are named by the event
Josh_Soref: the idl lets you pick the function name on the object
sicking: this is part of the
indexed db spec
... you pass it a callback for the transaction
... we can support function, or function-or-object
Marcos: looking in general how JS
... many people don't use the object form
<smaug> =FunctionOnly should be removed from the spec
mjs: to make this clear so we
stop talking about handle event
... can you give us the name of the name on the callback object
darobin: what is the color of the bikeshed?
Marcos: it's called handleEvent
sicking: let's pretend we renamed
this to transactionStart
... it would be a single function name, since we only do one thing
AlexRussel: if this is the beginning of having well named properties for callback objects, that's great
[ scribe repeats what Smaug said ]
darobin: I agree
... it should be transactionStart
mjs: WebKit has usually not done the FunctionOnly bit
[ Good bikeshedding, we picked a non black color ]
sicking: bug 14393
... i think i've already fixed it
... bug 14404
<smaug> FunctionOnly is always a spec bug except with onfoo event listeners
Israel: this related to not
knowing which version you were working on during an abort and
wanted to do an upgrade
... this related to an exception/event type not? having a version or something
[ No one seems to really remember tihs ]
... with an optional parameter, how would you get the version?
sicking: database.version in the upgradeneeded or the callback
Israel: if you aborted it, and you're outside the upgradeneeded
Israel: I think this predates an [optional] paremeteer
sicking: if you fail to
... which is where an upgradeneed happens
Israel: I think you can close the
... i don't think we need it anymore
sicking: we need to specify
something, because it's unclear in the spec
... bug 14405
... - i fixed that
... bug 14408
... - this is based on a usage pattern we saw
... as things stand now, if you open a cursor and in the callback and you do a bunch of things, and expect the cursor to progress
... having to call continue at the end is hard
... as soon as you call continue, getting .key/etc will trigger an exception
... we propose that once the cursor has recieved its first data, it won't throw
Israel: so it's just caching data?
sicking: this is because of request objects
Israel: so this is different than calling continue twice?
sicking: yes, that still throws
michaeln: what happens when you call continue on the last cursor?
sicking: either we make it start throwing, or we can leave the values as they were
michaeln: this came up recently
in code review
... and the response was "oh, i don't think tha'ts specified"
sicking: in general, the spec tries to agressively throw
michaeln: where you're changing
the behavior of aggressive throwing
... it needs to be fleshed out
sicking: i think i offered to fix this bug
i/start throwing/... there isn't a reference in the callback (it's null), but you can have another reference to it elsewhere/
sicking: bug 14412
... no brainer, we should do that
... bug 14441
... - just outdated, should remove that note, editorial
... bug 14488
... - missing annotation
... that's it!
... what do we return from delete operations?
Israel: I'm ok with not returning anything.
sicking: the spec says to return
true if it deleted something or false if there's nothing to
... in some casw, that would be useful
... this is asynchronous
sicking: this could be slower to
... and since we don't know if someone's going to use it, we already have to dig it out
... the speed cost is totally implementation specific
... my preference is to return nothing, to be safe
... you can always get the information, although it's probably slower - by calling count first
Israel: we're ok not returning
... as long as you end up in a success handler
... the issue was, what happens when you're deleting a range
... and you can't delete all of the range?
... and we agreed to throw two kinds of errors
sicking: if you fail to delete everything, you always have to revert, since all actions are atomic
Israel: one thing that would be
... we started putting out there a test called LAteral
... we'd like to get feedback from all implementers to see how interoperable we are
... i believe the set of tests are for the old set version
sicking: we already landed the change
Israel: we'll try to revise the
... open-with-version is the new api to replace set-version
[ That was answered for the Scribe ]
sicking: unfortunately, all of
our tests rely on the error event
... and they use generators
... JS Harmony generators
Travis: you can always stick things into the submissions folder
sicking: we'll need to go through our tests and rewrite them to not use generators, which are convenient to our test writers, but not portable
adrianba: it'd be helpful if you submitted them so we could see coverage and avoid duplication
darobin: and someone might
magically do the conversion for you
... i'm hearing whispers about LC
sicking: we might be able to do
LC this year
... we need to fix these bugs, but they're not much work
RafielW: from Google
... I'm curious to know if anyone from Apple/Microsoft has an opinion
... I'm reading it right now
weinig: Sam, Apple
... in a similar vein, we've been working on other things, and it hasn't been a high enough priority
... it's been moving pretty quickly and doens't seem bad
... it's good if it ties in with undomanager
Travis_MSFT: this is MutationObserver?
<anne> wait is this about mutations already?
[ Group apologizes to people not present ]
[ we break for 10 mins to let those 3pm people to arrive, please arrive promptly ]
<Ms2ger> [ Threats of hunting down people who are late ]
<Ms2ger> [ Robin, be warned ]
<Ms2ger> OH: I don't believe in the internet
darobin: it's 3pm, we're starting
Travis_MSFT: Would you like to tell us about MutationObservers
RafaelW: ok, so an overview
... the intent is to be a replacement for DOM Mutation Events
... the fundamental difference
... is mutation events try to project an abstraction
... that things are going to be dispatched synchronously
... that turned out to be problematic for a number of reasons
... MutationObservers are different
... you can register an observer to express an interest in a certain set of mutations
... and you'll get a list of things that have happened
... it's a batched list of things that have happened
... since the last time you were called
... the other interesting part is the timing of delivery of mutation records
... there was a pretty long discussion on Public-Web-Apps about this
... the people discussing this
RafaelW: arrived at what smaug
coined as "the end of the microtask"
... for the delivery of mutation events
... it means mutations are delivered at the end of the outermost script execution
... if outside such a thing, at the end of the current task
... as part of the single Turn, before painting
... otherwise you see artifacts
weinig: can that be defined in terms of the event loop?
anne: currently painting happens just after Task completion
RafaelW: currently painting has a
gaurantee (ignoring Modal dialogs)
... but you may get called before the end of a task
... if a synchronous event is handled
... say for mouse down
... and mutations happen as part of those handlers
... then you'll get something delivery then as part of that outermost
sicking: my understanding of when
it's defined to fire
... for example the Load event for XHR
... it fires at the end of each event handler
... let's use a click event handler
... it fires at the end of each event handler on each event target
... it happens multiple times during the call to dispatchEvent()
... so if you click on an element 3 elements deep
... you call on 2 elements in capture
... on target
... 2 on bubble
... You get it twice for each thing, potentially, but only if there are mutations
... the reason for this
... smaug was concerned that if we do it at the end of a task
... if each event handler is independent
... and doesn't know what one might do
... invluding doing a sync XHR
scribe: during one of those, we'd
need to fire these there
... there's a risk of an actor
anne: what if an actor calls showModalDialog
sicking: yes, but it means you can only shoot yourself in the foot
anne: that's acceptable
RafaelW: smaug are you
... can you explain more?
smaug: the idea was to
encapsulate the mutation
... web pages cannot detect what is a task
<anne> ^^ "that's acceptable?"
smaug: you may dispatch several
events during a single task
... it's always when a event handler returns or a timer returns
weinig: does that mean that every
new api we define we'll have to define microtasks
... or do we infer it?
sicking: specifcation-wise, it
would probably be nice if they did
... but it should be pretty obvious
... any time you call into the web page
... that isn't inside another callback
mjs: in that case, it might be
... if this concept was codified in some more explicit way
... we do have the concept of calling into script and having it call out
... it seems we're in agreement in what it is
sicking: when i spoke to Hixie ,
he said there was something like that in html5
... used to figure out security for call stacks
... but yes, it needs to be codified
[ Hixie is no longer behind sicking ]
sicking: there's special handling
... MutationObserver callbacks themselves
... if you have 3 observers
... and you make a mutation to the DOM
... and #1 makes a mutation
[ Sicking will write this in ]
rafaelw: my mental model
... is the mutation observer maintains a pending queue to be delivered to its observer
... and when it's called to deliver, it delivers what it has to its observer
... and that observer can create work to be added to all observers' queues
<sicking> if you have three observers and a modification is made to the DOM, then we first call the first observer, then the second second observer. If the second observer mutates the DOM, we'll recall the first and the second one with just the second mutation, and then the third observer with both mutations
rafaelw: and the system loops around until it empties its queues
sicking: everyone will eventually
... and there's no inner looping
... we'll append and create larger loops
mjs: can you create an infinite loop with 2 listeners?
sicking: even a single listener can create an infinite loop
rafaelw: what would happen with
current mutation events?
... you explode the stack
... that coding error
... here is just an infinite loop instead of exploding the stack
... we talked about a fixed limit on going around
... the advantage of exploding the stack
... is that you can see a stack trace to understand what went wrong
... hopefully developer tools will evolve to help you debug the infinite loop case here
mjs: there would be a way to avoid starving the paint cycle
[ Scribe summarized poorly ]
mjs: it's possible to make a
... where you don't have an arbitrary fixed limit
... but you don't starve the event loop if you have a programming mistake
rafaelw: we talked about
... there are legitimate uses for going around the horn a couple of times
... and then let things settle down
... comes from the model driven use proposals
scribe: we were asked to slow down and look at the use cases
rafaelw: imagine you were using a
JS library to do templating
... and used something like jQuery to do a UI
... and it wants to go decorate the page w/ more DOM
... and you used a constraint library to manage forms
... so the templating library might produce more jQuery stuff
... and the jQuery stuff might trigger more work for the templating
mjs: that seems like a Use Case
where it's easy to create something that never terminates
... i agree it enables you to do things you could not otherwise do
ojan: Ojan, Google
... as long as we agree
... mutations during one of these callbacks should get delivered eventually
... this error will either result in a hang, or burning cpu indefinitely
... i'd rather the hang
... rather than burning cpu
... i'd rather a limit and an error
rafaelw: i mostly agree
... i just don't want to create a situation where a developer doesn't know if he'll run before a paint occurs
mjs: you have the situation where
each piece of code has observers
... you need to globally analyze to determine if it will finish
Travis_MSFT: they need to be
... you could get into an infinite loop
... if jQuery included things which the validation system depends on
... which depends on the third component
... but in most cases, i don't think that will happen
... you might have a queue of 3 or 4
mjs: the loop was claimed as a UC
Travis_MSFT: i agree, but
disagree on a hard limit
... the distributed UC is potentially difficult
ryosuke: we already have this
problem with the current system
... i don't see this as introducing new issues
mjs: given how bad mutationevents
... i don't support "no worse than them" as justification
weinig: yes there are problems,
yes this makes things better
... if we could avoid more problems, that's better
darobin: the situation you've described is a corner i've painted myself into many times
weinig: in the end, those risks
are going to be minimized by something XBL-ish
... or component modelish
[ laughter ]
mjs: there's really 3 basic
things for this issue
... 1. repeatedly cycle until all queues are empty
... 2. have a fixed limit
... 3. at some point, delay delivery to avoid starving the event loop
... this should be on the mailing list
ACTION rafaelw to send how to handle single pass not emptying all mutation queues to the list
<trackbot> Sorry, couldn't find user - rafaelw
[ anne asks a question ]
anne: call dispatchEvent() from
... where does that get trigger the mutation observers?
sicking: the outermost thing is
always a callback
... which is a microtask
... if you call dispatchEvent() in there,
... the mutation observer calls back from the end of the outer microtask
... it's like a function call
anne: tasks that are queued are
... yes, they are outermost, so they're special
rafaelw: are you concerned, or not understanding?
Travis_MSFT: i'd like the spec
describe the scenarios clearly
... perhaps even so people can visually see
ojan: and if sicking could recall the thing Hixie said, that'd be good
smaug: i need to finish the
... to decide if it's good
darobin: does this go into
... does anyone care?
<Ms2ger> I do
<Ms2ger> As mentioned before
<anne> you can edit it :)
ryosuke: i've heard that they relate to DOM4 and should probably be there
anne: i do think it should be in
... because every other spec that intergrates should work with it
darobin: we seem to have violent agreement there
<Ms2ger> I'm in violent agreement with anne :)
darobin: anything else to discuss?
Travis_MSFT: do these observers include stylistic properties?
sicking: most stylistic changes
don't directly do this
... but many times you trigger a style change by setting an attribute or inserting something, which would itself be an observer notice
rafaelw: there's an attribute filter
darobin: perhaps there should be something specific for a specific class value
rafaelw: we agreed this is
probably the 80% use case
... there was an earlier proposal from microsoft called watched-selector
weinig: i want to echo that
... the extra class list on element was the favorite thing
... special casing class might be valuable
ojan: i really liked the
... it's more generic, over a selector instead of just a class list
scribe: what i like about this is that you can implement watchSelector on top of this
rafaelw: it's on my list to open source a watchSelector reference impl on top of this
darobin: anything else?
[ No ]
[ Break until 4pm -- for server sent events ]
[ darobin bryan will introduce, it's up on the screen ]
bryan: I sent to the list a
... 2 years ago
... at TPAC here
... We had a discussion at the HTML WG about connectionless push
... the text at the time was fairly generic
... the ability to use connectionless methods
... not having to maintain keepalive
... the intent in that spec, still informative
... a list of things that might occur in the process
... this spec
... I've been involved in OMA since 2000
... involved in the push work in OMA since then
... we recently completed work within OMA
... this api is enough to form the basis of an extension to event source
... it provides a way to use SMS
... as an extension to http push
... events are passed up to the application, in this case, the OMA runtime
... when it's advantageous to save resources
... it's possible to coalesce these into a unified message
... event source didn't define these because they were out of scope to the spec
... I have a diagram here showing how apps could be deployed
[ bryan describes the diagram ]
[ The diagram is: http://bkaj.net/w3c/eventsource-push.html#introduction ]
bryan: this doesn't modify the
signature of Event Source
... down the road, we might create a persistent registration
... to let events wake up applications
... you have the desire to connect two new barers through uri
... you can use a registered urn that defines OMA Push
... within the IMS framework
... events are delivered using the same model as Event Source
... although the event type is sent to SMS for SMS
... and OMA Push for OMA Push
... you don't get onMessage() since these are not message events
... with OMA Push
... the simplest way was to create a sequence of strings
... so the application can receive all of the data as a single event using the event stream concept
... in this case, i pulled out the xml document, the url, and the text message, and present it
... for sms, the sms text message gets put into the event and delivered
[ bryan describes second diagram ]
[ bryan describes third diagram ]
[ bryan mentions Widget contexts but glosses over it ]
bryan: developers need to
consider filtering for security considerations
... just as in web messaging
... accepting "*" is the responsibility of the application choosing to do so
jcantera: Jose Cantera,
... how do you intend to progress this?
darobin: charter wise, it's in
scope to this group
... if this group is happy to do it
... do you think it would make sense
... one good thing is that it lets web apps have the same notifications as native apps
... and it shields web apps from complexity
... would it make sense to hide the distinction between OMA Push and SMS?
bryan: i considered it
... but, how do you deal with different framing formats?
... in OMA Push, you can deliver any content type
... the headers are important, you need to know the mime type
... those elements are important
... for a server to provide to the app
... i couldn't figure out how to combine that
weinig: what mobile OSs support this?
bryan: I prototyped this in
... I believe almost any OS in a smartphone class
... allows a developer to attach to network sources
... and allow someone to act as an agent for this
... in mid tier devices, that tends to be more complicated
lgombos: Laszlo Gombos, Nokia
[ Lost, sorry ]
sicking: we talked about this at
... but we created something very different from this
... there are two unfortunate things here
... 1. I'd like to hide whether messages are from TCP/IP or SMS or OMA Push
... (I don't know anything about OMA Push)
... - it feels like the goal was to expose OMA Push
<heycam> anne, no it's at 4:30
sicking: The goal at Mozilla was ... How do we expose SMS over a channel that isn't TCP/IP?
s/anne, no it's at 4:30//
scribe: the other part is
requiring permission from the user
... that severely limits how many users allow that
... if it's a little bit sensitive, people are still rightfully worried
... people press no, which is better than just pressing no
... we were hoping to provide something simpler/safer
bryan: there could be prearranged
... but it would be better for the user to have already trusted the app and not overburden them with prompts
darobin: what sicking was getting
... is providing an *always* safe subset
... to avoid getting permission
... this is more powerful, and "easier in terms of security"
bryan: "how do you make this
... look at XHR, the agent says "i want / i'll take these mime types"
... if we could take event source and say "i can accept these mime types"
... that would let me decide if it was safe to deliver it
... because i didn't want to change event source, i couldn't do that
darobin: i think that's an option
on the table
... i'm hearing interest in doing something around this
... would anyone object to the group working on this?
... it's in charter already
[ Chatter ]
sicking: this feels different
enough from what we talked about at mozilla
... it feels like a different deliverable
... if we can solve it by just adding a header
shepazu: would you be comfortable
having a line in the charter scoping it more tightly?
... why don't we three right a deliverable line for the charter?
darobin: to avoid waiting for
... we should agree on a scope
... bryan it'd be good if you could send use cases
... sicking, it'd be good if you could send something
mjs: weinig asked earlier if this
is implementable onn iOS
... i believe as presented, the answer is no
... iOS doesn't give applications the ability to receive SMS
... to me, that says that a design that does not force the web page to choose a transport would be better
bryan: i've said "any available barer would be good"
darobin: ok, based on the email you all send, we'll scope the work
scribe: In this session, I want
to let people bring up issues
... and discuss how we might go about testing
... and third, what are the time frames for implementers (smaug asked this)
... do you mean consume the syntax?
heycam: I don't mean specifically that, perhaps just conforming to its behavior
weinig: one thing we talked about
in terms of testing WebIDL
... is to test it in terms of specs that are speced in WebIDL
... for instance Canvas
... uses ovberloading
... and things like prototype chains
... testing people's implementations of generating code, i don't think it's worthwhile
... you could hand write all the bindings, and still be compliant
heycam: i agree, that's the only
... i think someone could come up with a set of properties for testing
mjs: the way WebIDL is written,
it's targeted at spec writers, not browser vendors
... it creates an indirect relationship
... indirect testing through testing of other specs seems the only way of testing it
... which unfortunately creates a circular dependeny for progressing on the REC track
<dom> [I don't think see why this would be circular? surely we *can* create tests for specs that aren't in CR yet]
weinig: we always do that when we test XHR, we test JS
mjs: yes, we do
jrossi2: in particularly
... when you test foo-spec, you test webidl
Travis_MSFT: I agree
... and as we march to LC, we need to mark things as AtRisk
darobin: we should just kill it
heycam: and the only one is modules
weinig: does that include namespace objects?
AdamBarth: you can look at the specs as testing it
heycam: yes, but it's harder to test automatically
darobin: things written with ReSpec are pretty easy
AlexR: Alex from Google
... i'm not sure if this is the right forum for this
... i think the entire java language indings should be dropped
scribe: second is there are
several instances where webidl doesn't serve JS well
... 1. a TC-39 meeting
... several months ago
... interface objects which are reified
... do not act like function objects
<gsnedders> One option for WebIDL testing is some sort of tests designed to be run in a browser-specific way against the interface generation
scribe: do not behave normally, they aren't callable
[ scribe lost thoughts ]
heycam: I agree with this
... it's unlikely authors will be doing 'throw typeerror'
... things which are unnewable
... things where it doesn't make sense to be able to new them
<anne> new Math()
AlexR: i take the concern
... it's a risk
... the idiomatic way of doing that in js
... is mixins
<anne> (gives a TypeError)
AlexR: the artifact way of doing
that would be still newable
... the reality is that today, webidl doesn't specify something "reasonable" that could be impleemtned yourself in JS
weinig: that's not necessarily
the goal of WebIDL
... the goal of WebIDL is to define how things are implemented today
... and how they should be impleemnted
AlexR: thenI suggest webidl is mischartered
a way to subclass things other than Object
... fortunately, almost everything is Objects
... I know you suggested something using Object.call
... but I didn't hear any inmplemetners interested in doing that
... and it seemed like something for TC-39 to do
AlexR: i should put on my TC-39
... and note that this discussion was something that happened @ TC-39
... and brendan and I agree that everything you can do to an interface, should be newable
... and yes, Arrays are odd
... and you sdhould throw things back at uws
... and there are things in ES6, proxies
... which should address it
sicking: what acts as normal JS
is a matter of definition
... for example, the array class, and even the string classs
... has built in behavior and doesn't allow you to subclass
... and we're following those models
AlexR: you're still failing
... since your objects claim to chain to Objects
sicking: but Array claims to chain to Object
AlexR: but everything that WebIDL defines has intrinsic behavior
sicking: but that's how it
... the fact is that TC-39 hasn't solved this problem for any of these things
... it's actually more, bz had examples
AlexR: Math is an Object, not a Function
heycam: In the Spec, they are all
Function objects, they are defined such that when called they
throw type error
... which you can do in JS
AlexR: do we still have a
separate constructor property in WebIDL?
... throwing by default is a bug
sicking: moving beyond low level
... heycam wrote an example, "new Node" doesn't make sense
mjs: every DOM object that's an object is a specific Subclass of Node
AlexR: but that invariant is controlled by AppendNode
<heycam> The spec says "Interface objects are always function objects."
sicking: but if it's several weeks of work in order to do something which no one can do anything useful with, then it's a waste of time
weinig: what's the argument for making node
sicking: all the intrinsic behavior of Nodes is based on which Node subclass it is
AlexR: then calling it and newing it throws
heycam: is it worth it to handing back a non useful thing?
Travis_MSFT: the answer is no
AlexR: i'm not saying that you
should turn off the ability to new/call
... i'm asking you to turn off the default
anne: then you'd require a lot of specs to change most of the specs
AlexR: i'd argue that for html element types, it's mostly a bug
jrossi2: no, there's more than one interface per element
anne: because the tags all share an interface
AlexR: so you can't create a tag
... you haven't thought about it hard enough
anne: we have thought about constructors a lot, especially because you brought it up
mjs: there are two separate
... one is New
<anne> wrong or not, without use cases this is not going to fly
mjs: and the other is
... in js, only Object supports Subclassing
[ mjs and AlexR argue ]
mjs: you should fix JS first before we change
AlexR: we have misfeatures in DOM based on document.createElement
mjs: the goal of WebIDL is to
describe the actual semantics of DOM bindings and to get
... it is not the goal of WebIDL to transform the philosophy of how DOM bindings are built
AlexR: the issue of default,
shouldn't be the way of forcing the default
... because as anne says, people will just put no constructor everywhere
anne: that's makework
AlexR: creating an instance
... in the same idiom as anything else i can in that system
weinig: that's something whicih as mjs said
AlexR: will there be a WebIDL version which changes this?
[ We are at an impass ]
[ Should we drop Java? ]
heycam: oh, i didn't respond to
... if we particularly don't care about other bindings
... and i'm sure AlexR would argue we shouldn't
<gsnedders> I keep on grimacing everytime subclassing is mentioned… because JS doesn't scarcely has classes. :\
heycam: should we actually alter
WebIDL to reflect something closer to JS
... that is something to consider, but it would take some time to do
Marcos: have you done the bindings for WebIDL in java?
heycam: one project I'm involved in has a Java based DOM
shepazu: i wanted to talk about process very briefly
<gsnedders> Does it look as if anyone will have met CR exist criteria for the Java bindings by the time they have been met for the JS bindings? IMO that's the relevant matter.
shepazu: dropping Java would mean we don't need 2 java implementations to get to REC
<gsnedders> The Java bindings are fine provided they don't hold up the spec.
<gsnedders> (They can always be split out into a separate spec)
mjs: getting two interoperable
implementations of java bindings to test all of the features of
... would keep the spec from REC forever
shepazu: the Staff view on
... is that if for each feature we have 2 specs in CR
heycam: the plan is to only have 1 spec consuming some of these items
shepazu: we can be fine about
... don't let the process for a normal spec drag us down
... we can come to an agreement on the exit criteria
... we're flexible on how we judge the passs criteria
<gsnedders> Can someone ask what the staff view is on impls of the bindings?
mjs: i think we need actual
implementations of specs using this feature
... part of what we're evaluating is to ensure that all of the details of what it says happen are actually practical/possible
<dom> (I think Java bindings should be split into a different document)
weinig: i had a bunch of
... 1. should long long stay in the spec? given its wierd behavior in javaascript
... given the inability of js beingable to represent numbers consistently
heycam: the issue being numbers
in js over 2^53 get squished into a double
... we talked about creating a class
anne: it's used in progress events
mjs: the loss of precision
... it's more of an issue if we lose that detail in a movie
... the progress events of loading a movie from xhr
... i'm more curious about your opinion
<gsnedders> bigints should be readded to WebIDL after they're in ES
<anne> Josh_Soref: I worry about data loss with this
<anne> Josh_Soref: nobody else worries about it :(
<gsnedders> (i.e., they should be removed in the short-term)
<anne> (roughly what Josh_Soref said)
mjs: 2. should we treat an
undefined value for a key in a dictionary the same as non
... that would be fine with apple, especially if mozilla is ok
... what we do currently is inconsistent for our dictionaries
... etierh way sounds fine, it's usually a programmer error
heycam: sicbrought up cases like that where you deliberately get something as undefined
mjs: so that sounds like a use case
heycam: sicking said it's consistent with missing arguments to a function
heycam: we're making the argument that people compare to argument instead of checking
<gsnedders> I think someone needs to look through ES and see where [[HasOwnProperty]] is used and where undefined is used
[ see brendan's argument on list? ]
weinig: the other one discussed
this week is remove FunctionOnly for callback
... implementers have been inconsistent wrt how they use that
heycam: this might be a case
where using interfaces resulted in
... creating an object with the property called handleEvent
weinig: i was actually saying
allow both in all circumstances
... it's not like we can make addEventListener handle this
heycam: i did it as the default
jrossi2: i found the legacy
handleEvent all wierd
... and developers would like to support it everywhere
weinig: in webkit, we allow both
anne: it is defined as Callback
... i think it's removed everywere except onFoo
weinig: WebKit allows it everywhere, so
Travis_MSFT: I'd like to point
out that in my years, i never heard of that
... i'd rather default to FunctionOnly
AlexR: my preference would be
that if Object style is supported
... is that we attempt to allow same name as event name in addition to handle event
... so that you can have different colors
... handleEvent is the thing that doesn't do nicely for all event handlers
heycam: if that's the direction
we want to go, then we need to support Object style
... so you want to remove FuinctionOnly from the spec so you can only do both
weinig: i didn't realize that hixie was using it for attribute event listeners
heycam: i could inroduce function to actually mean function
anne: we could add eventhandelr for that
heycam: i'll make the change about allowing typedefs to put some extended attributes on a type so whenever you use a typedef you get the attributes from them
... i ask this every time i see you
... do people/do other specs use Sequence, and Array?
heycam: now there are
weinig: the next thing, an
... is iteration order in for-in of properties on interfaces defined?
heycam: we were trying to defer to TC-39
weinig: TC-39 doesn't define them
for host objects
... in webkit, it's a random order
<gsnedders> Does ES5 not define them as undefined for host objects?
<gsnedders> Like, does the definition as undefined not apply for all objects?
weinig: i've not heard of any bugs regarding iteration order
Travis_MSFT: yes, we've heard of
... we end up breaking them every time we ship IE
... it doesn't break many sies
... more often than not, it's a testcase
... i would not want them to be defined, because it would be particularly hard
... in the spec, there's some mention of ordering
... named and indexed properties
weinig: pragmatic question
... on Window, in the browser
... ... are you comfortable with the hooks on Window
... in webkit first look at the this, and then look at the that, and ...
... there are multiple catchalls that have to be iimplemented in order
... does anyone know if that's speced anywhere?
heycam: yes, between a combination of things in HTML and WebIDL, it should be completely defined
heycam: there's a bug that lists the order, and Travis_MSFT checkked it, and it didn't seem to hit any problems
weinig: it seems like we need lots of test cases for it
Travis_MSFT: i'm waiting for firefox to implement that part of the spec (sic)
weinig: the only problem we could hit is "var location;"
heycam: one question for
... the approach of having idl attributes mapped to accessor properties
... there's an issue Travis_MSFT identified
<heycam> assigning to Element.prototype.onsomething
heycam: there's an issue travwith an old version of prototype.js breeaking
<heycam> since on* handlers are now accessor properties on the prototype that throw if their this object is wrong, this was a breaking change for some sites
<heycam> where the previous implementation was to have those properties as data properties on the instances rahter than the prototype
heycam: because it checks the
this of something
... are people happy with that approach?
... i particularly value it for overloads
... it's easy to replace functionality when you need to
<trackbot> Sorry, Josh_Soref, I don't understand 'trackbot: yes'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
weinig: yes, no issue
... we're worried about performance
AlexR: array.length has two
... it's a getter/setter pair
... that can be modeled as getter/setter today
... second, if you write to an index property beyond current length, there's a magical put
... shrinking can be repaired
... growing requires morework
weinig: will length be moved to the prototype be moved to use getter/setter
AlexR: it isn't clear how it will be resolved
heycam: earlier in the
discussion, we brought up the idea with a more JS focussed
thing which might replace WebIDL
... not right away
... we didn't have people chime in
[ what would it look like? ]
heycam: something where the actual constructs in JS would sound like JS
darobin: why not use JS?
heycam: because it wouldn't be very concise
Travis_MSFT: it's a tricky thing
... if you contemplate things the way ECMA does it, you have to be more verbose
... on the other end of the thing, you
... it might be an interesting exercise, but i'd like to finish webidl first
mjs: there's some value that
webidl is somewhat decoupled from js
... js is the only langauge that's relevant for api specs
... maybe someday every browser owill have python or dart
... if it does, then we will regret it if we define things too tightly
<heycam> Josh_Soref: one of the things which DAP was looking at was the ability to specify SOAP replacement
<heycam> berjon: json-rpc using webidl
AlexR: having designed DOM for
DART, the right interface will be a new way of doing
... we wound up doing something WebIDL
<heycam> Josh_Soref: they wanted to define an API for things where the implementaiton might not be a host object, it might be JS
<heycam> ... but they want to define it in Web IDL
<heycam> ... and in doing that, we were toying with the idea of writing a WebIDL to JSON binding
heycam: you're talking about
using WebIDL to define a ReSTful interface
... i haven't seen a lot of discussion about that
... outside a bunch of people mentioning it on the DAP list
darobin: it's actually feedback
from webkit that brought this up iniitally
... define a mapping to json objects
... and define a mapping to json ipc
... it would be defined separately
... the way forward on that, is that i'll finish my JS prototype of it
... and see if it flies or crases
AlexR: there is a value in having
a base description of what the apis are
... in most implemenetations those are in C+++
... and those will correspond fairly closely to the IDL
... but at the same time, having something that is too close to C++ doesn't serve JS very well
mjs: in webkit today, we generate
mu;multiple bindings from idl
... they are just used ffor portions of the api exposed
... ObjC, C++ bindings, mapping to various frameworks
... possibly Python and Gobject
... in some cases, people haffve specifically mentioned a desire to align with the relatively well known JS APs
... as a value relatively close to the JS for users of their language
... there may be value for a single interface description with mappings to languages
AlexR: mappings doesn't mean
... if we are designing a multilanguage thing
... then we have a responsibility to all of them
darobin: i think that's a straw
... we are designing w/ js very much
... as much as i'd like to see a v2
... we're not going to change the course very much
... if you want a v2, bring a sketch
heycam: a bunch of things are collapsing number types or renaming some keywords
mjs: the number types are sueful
because they define error checking at the interface between the
js interface and the underlying implementation
... having a single number type would require each spec to explain what happens when one passses a non interger
... the case of i only accept integers in this range is fairly common
Marcos: i'd like to see more examples in the spec
heycam: i try to include one example per construct
Marcos: i'm doing a review of it
anne: are we doing another
... and if we do, could we add String Enumerations
... as a replacement for string constants
heycam: I talked to the WebPerf
... and they're happy with dropping that
... wrt LC, do you have to if you make normative changes?
darobin: if you make changes
which would invalidate a review, then you're supposed to go
back to LC
... normally we would have to go to LC, especially if we made this change
... LC isn't a big deal, it's just process
... we can have a 3 week last call, and if everyone is happy, just move to CR
... and start testing
... does anyone want to be the testing chief for webidl?
heycam: i thought that was only for new specs
Marcos: HTML5 tests most of it, right?
jrossi2: that's irrelevant, we need an example of each thing
<anne> heycam, what about AllowAny?
<anne> heycam, I guess you have that recorded somewhere...
Josh_Soref: can't we just create a table for each feature of WebIDL and an interface in a given spec for it
Travis_MSFT: i think we solve the Example requirement and Testsuite by correlating to Spec items
<scribe> ACTION: Travis_MSFT to lead testing coordination for WebIDL [recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action02]
<trackbot> Sorry, couldn't find user - Travis_MSFT
<MikeSmith> trackbot, status?
<scribe> ACTION: Travis to lead testing coordination for WebIDL [recorded in http://www.w3.org/2011/11/01-webapps-minutes.html#action03]
<trackbot> Created ACTION-638 - Lead testing coordination for WebIDL [on Travis Leithead - due 2011-11-09].
heycam: AllowAny is in the list of things from the LC feedback
<trackbot> ACTION-638 -- Travis Leithead to lead testing coordination for WebIDL -- due 2011-11-09 -- OPEN
heycam: it had implications relating to override
anne: I wasn't clear where it was used, apart from XHR
[ heycam talks about overloads ]
[ specifically String and Number versions with AllowAny ]
ACTION darobin to ACTION rafaelw (or the Google AC) to send how to handle single pass not emptying all mutation queues to the list
<trackbot> Sorry, couldn't find user - darobin
ACTION boarlicker to ACTION rafaelw (or the Google AC) to send how to handle single pass not emptying all mutation queues to the list
<trackbot> Created ACTION-639 - ACTION rafaelw (or the Google AC) to send how to handle single pass not emptying all mutation queues to the list [on Robin Berjon - due 2011-11-09].
darobin: any other issues?
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/EE:/EU:/ Succeeded: s/EE:/EU:/ Succeeded: s/EE:/EU:/ FAILED: s/EE:/EU:/ Succeeded: s/EE:/EU:/ Succeeded: s/writter/writer/ Succeeded: s/that is/that it is/ Succeeded: s/ack// Succeeded: s/RRSAgent: draft minutes// Succeeded: s/RRSAgent: draft minutes// Succeeded: i/Topic:/Scribe: Chaals Succeeded: s/??:/Travis_MSFT:/ Succeeded: s/Suresh/Balaji/ Succeeded: s/Balaji/nvbalaji/ FAILED: s|weinig|maciej| Succeeded: s/../.../ Succeeded: s/dg/dglazkov/ FAILED: s/..../.../ FAILED: s/..../.../ FAILED: s/..../.../ FAILED: s/valuale/valuable/ FAILED: s/..../.../ FAILED: s/..../.../ FAILED: s|s/..../.../|| FAILED: s/ewe/we/ FAILED: s/XXX/imperative/ FAILED: s/the,m/them/ FAILED: s/of company's/of Alex and company's/ FAILED: s/tready/ready/ Succeeded: s/form/from/ FAILED: s/Index/Indexed/ FAILED: s/hj/js/ FAILED: s/tihs/this/ FAILED: s/parameteer/parameter/ FAILED: i/start throwing/... there isn't a reference in the callback (it's null), but you can have another reference to it elsewhere FAILED: s/casw/cases/ FAILED: s/Travis/Travis_MSFT/ FAILED: s/doens't/doesn't/ FAILED: s/Public-Web-Apps/Public-Webapps/ FAILED: s/invluding/including/ FAILED: s/mjs/weinig/ FAILED: s/proposals/proposal/ FAILED: s/watched/watch/ FAILED: s/watched/watch/ FAILED: s/anne, no it's at 4:30// FAILED: s/helo/hello/ FAILED: s/dependeny/dependency/ FAILED: s/think/see/ FAILED: s/hheyyes/heycam: yes/ FAILED: s/indings/bindings/ FAILED: s/AlexR/heycam/ FAILED: s/whicih/which/ FAILED: s/mjs/weinig/ FAILED: s/sicbrought/sicking brought/ FAILED: s/sic/sicking/ FAILED: s/trackbot/Travis_MSFT/ Found Scribe: Marcosc Found Scribe: Chaals Inferring ScribeNick: chaals Found Scribe: ArtB Inferring ScribeNick: ArtB Found Scribe: Josh_Soref Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Scribes: Marcosc, Chaals, ArtB, Josh_Soref ScribeNicks: chaals, ArtB, Josh_Soref Default Present: tpac, Olli_Pettay, Ms2ger Present: tpac Olli_Pettay Ms2ger Soonho_Lee magnus krisk spoussa Jacob Israel SungOk_You Bryan_Sullivan Wonsuk_Lee David_Yushin_Kim Kihong_Kwon Jesus_Martin hao_wang Jonathan_Jeon Josh_Soref Robin Cameron JamesG Dom Jonas Doug Chaals Kris BrianR Magnus ArtB MikeSmith EricU LaszloG Sakkari WayneCarr Dowan adrianba eliot Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Tuesday.2C_November_1 Got date from IRC log name: 01 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/01-webapps-minutes.html People with action items: art charles travis travis_msft[End of scribe.perl diagnostic output]