| 00:01 | <tantek> | gavinc, oh like <name of company doing experiment> - blah |
| 00:02 | <tantek> | or perhaps short abbreviation instead of name, like ms- ;) |
| 00:22 | <gavinc> | hehe |
| 00:42 | <zewt> | my favorite HTML nonsense of the day: my wifi router uses type=password for keys, even though it fills out the current key, which just means I have to jump to the inspector to find out what the current key is |
| 00:44 | <zewt> | not sure if i should blame the router's HTML for that, or browsers for still not having any "show this password" context menu option on password inputs |
| 00:47 | <tantek> | Does the spec provide UI/UX guidance in that regard? |
| 00:48 | <tantek> | (for <input type=password> ) |
| 00:48 | <tantek> | zewt - feel free to file a bug in Bugzilla on it for the UI you'd like to see in the browser and we'll see what our security people have to say about it: bugzilla.mozilla.org |
| 00:49 | <zewt> | haven't had much good experience filing bugs on firefox so i'm inclined only to spend time for security issues, heh |
| 08:12 | <hsivonen> | surprising preliminary result: http://lawrencemandel.com/2012/07/23/mobile-web-compatibility-july-20-2012/ |
| 08:15 | <tantek> | hsivonen wonderful news |
| 08:16 | <tantek> | so perhaps we don't have to sacrifice the platform for the sake of webkit compat |
| 08:16 | <rniwa> | nice! |
| 08:18 | <hsivonen> | tantek: whether it's wonderful depends on the point of view. It's not wonderful that we can't improve compat unilaterally in our code without evangelism. |
| 08:19 | <hsivonen> | (also, the post doesn't say if the aliasing happened in the CSS parser only or also in CSSOM) |
| 08:20 | <tantek> | hsivonen - john's crawling showed evidence of sites using prefix properties in CSS, not CSSOM |
| 08:20 | <tantek> | if you have evidence of CSSOM dependencies, perhaps you can provide them |
| 08:20 | <rniwa> | hsivonen: i guess a good question to ask is whether the experience was worse on Firefox than on WebKit. |
| 08:20 | <rniwa> | it might be that those websites don't depend on webkit prefixed properties |
| 08:21 | <tantek> | rniwa - the websites were found to have stylesheets that had webkit prefixed properties in their CSS |
| 08:22 | <tantek> | whether or not the properties actually matter to the UX of the site - that's a different question |
| 08:22 | <rniwa> | tantek: sure but that doesn't necessarily mean that they "depend" on them |
| 08:22 | <tantek> | like does anyone notice a 1px difference in rounded borders? |
| 08:22 | <rniwa> | tantek: exactly. |
| 08:22 | <rniwa> | tantek: i may use webkit prefixed properties for some minor cosmetic reasons but it may not affect UX much. |
| 08:23 | <rniwa> | in fact, graceful digression is one of the strengths of css. |
| 08:23 | <tantek> | rniwa - precisely - and one of the reasons why the chicken-little "implement all the webkit prefixes!" crowd was talking irrationally |
| 08:24 | <rniwa> | tantek: yeah… that was quite radical after all. |
| 08:24 | <tantek> | which is why when I introduced the problem in the CSS WG in February, I pointed out we'd only change things justified by data, not the ranting emails/blog posts calling for massive changes in a reactionary manner. |
| 08:24 | <rniwa> | tantek: i'm glad people have realized that prefixing DOM APIs is a really bad idea now |
| 08:25 | <tantek> | rniwa - really? what's the evidence for that? |
| 08:25 | <tantek> | DOM APIs may have a different dynamic than CSS properties - that I'll grant |
| 08:25 | <tantek> | but I haven't seen the negative evidence that you speak of |
| 08:26 | <rniwa> | tantek: well, imagine we had document.webkitActiveElement, document.mozActiveElement, document.mzActiveElement, etc... |
| 08:26 | <rniwa> | ms* |
| 08:26 | <hsivonen> | tantek: IIRC, we had a bug where a site used Modernizr to detect support for 3D transforms and then used WebKit-only 3D transforms if Modernizr said yes |
| 08:26 | <rniwa> | hsivonen: :( |
| 08:27 | <hsivonen> | tantek: it's of course possible that it was an isolated incident and not a pattern |
| 08:27 | <annevk> | tantek: instead you rant about other browsers that did feel justified to support -webkit-border-radius? |
| 08:28 | <tantek> | annevk - data for different browsers was different |
| 08:28 | <tantek> | or so I'm assuming - only Mozilla published data on this AFAIK |
| 08:28 | <tantek> | annevk - if you have sources of data for other browsers, please provide and I'll happily link to it |
| 08:29 | <hsivonen> | rniwa: how is the realization that prefixing DOM APIs is bad showing in practice? |
| 08:30 | <hsivonen> | (I agree that prefixing DOM APIs is bad--I wish Mozilla didn't do it.) |
| 08:30 | <rniwa> | hsivonen: i think people are prefixing new DOM APIs less. |
| 08:30 | <tantek> | would prefixing the Localstorage APIs have helped with the incompatibilities that we've seen there? |
| 08:31 | <hsivonen> | tantek: no, AFAICT |
| 08:31 | <tantek> | since that was an instance of *not* prefixing, and then being stuck with implementation-specific behaviors |
| 08:31 | <annevk> | localStorage was mostly fast adaption by everyone and then realizing it might not be an ideal API |
| 08:31 | <annevk> | adoption* |
| 08:31 | <hsivonen> | tantek: did we get stuck with implementation-specific behaviors? I thought we got stuck with ill-considered specced behavior |
| 08:31 | <tantek> | specificly, IE8 localstorage, threading |
| 08:31 | <tantek> | hsivonen - not sure |
| 08:33 | <tantek> | though I suppose implementing WD spec'd behavior is another use-case for prefixes |
| 08:33 | <hsivonen> | tantek: Hixie tried to fix the multiprocess race conditions after the fact, but no one seriously wanted to implement the fix |
| 08:33 | <tantek> | no one wanted us to implement the fix because they didn't want their code to break |
| 08:33 | <tantek> | though if their code was dependent on a prefixed API |
| 08:33 | <tantek> | then we could have fixed it in the unprefixed API |
| 08:33 | <tantek> | or go from mozFoo to moz2Foo etc. |
| 08:34 | <annevk> | no that was not the reason tantek |
| 08:34 | <annevk> | the fix was simply not worth the effort |
| 08:34 | <tantek> | annevk - happy to be corrected |
| 08:34 | <hsivonen> | tantek: a truly proper fix is a completely different API, and we can mint a new API even if the first attempt isn't prefixed |
| 08:34 | <hsivonen> | tantek: the new API is IndexedDB |
| 08:34 | <hsivonen> | tantek: which for many localStorage uses is an overkill |
| 08:35 | <hsivonen> | tantek: so we really don't have an API with callbacks but otherwise localStorage-level simplicity |
| 08:35 | <tantek> | and is underkill on browsers that don't support IndexedDB |
| 08:35 | <rniwa> | wow! youtube.com just updated their UI. |
| 08:35 | <hsivonen> | tantek: the fix that would have retained the API structure of localStorage was too complex to be implemented |
| 08:36 | <hsivonen> | tantek: besides, localStorage already was the second iteration. after globalStorage |
| 08:36 | <hsivonen> | and globalStorage was unprefixed |
| 08:36 | <hsivonen> | and we still removed it |
| 08:36 | <tantek> | hsivonen - what I find odd is that cookie API has existed for years, and a simple attempt to expand it was apparently much harder than expected. |
| 08:36 | <tantek> | twice |
| 08:37 | <hsivonen> | sure, Hotmail broke, but if it had been mozGlobalStorage, Hotmail would have used it and gotten broken upon removal anyway |
| 08:37 | <hsivonen> | tantek: the cookie API has race conditions, too |
| 08:37 | <hsivonen> | tantek: but it turns out they are race conditions we can live with without the sky falling |
| 08:38 | <odinho> | storeGet = function(key, cb) { db.transaction('store').objectStore('store').get(key).onsuccess = function(e) { cb(e.target.result) }; } |
| 08:38 | <tantek> | the storage API debacle actually provides a strong case for versioned APIs (if not prefixed) |
| 08:38 | <hsivonen> | If I understand correctly, the cookie API has always had race conditions even in single-threaded browsers |
| 08:38 | <odinho> | Yeah, kinda verbose, -- but it's not many lines to shim a very basic easier API :P |
| 08:39 | <odinho> | (you would also need a similar Set function, which would be the same only using add instead of get, and you'd need an init function opening the db) |
| 08:39 | <hsivonen> | tantek: why? globalStorage, localStorage, Web SQL Database and IndexedDB don't have namespace collisions even without prefixes |
| 08:39 | <tantek> | local storage is particularly critical on mobile, and due to lack of IndexedDB on Webkit - telling webdevs to "just use IndexedDB" is impractical |
| 08:39 | <tantek> | so instead we wait for frameworks to abstract some *other* storage API on top of whatever each engine happens to support |
| 08:40 | <hsivonen> | tantek: why would it be more practical to tell them to use a bunch of different localStorages? |
| 08:40 | <tantek> | e.g. is there a IndexedDB polyfill that uses WebSQL underneath on Webkit? |
| 08:40 | <hsivonen> | IIRC there is |
| 08:40 | hsivonen | searches the Web |
| 08:41 | <tantek> | hsivonen - use bunch of different localStorages = can actually run on multiple browsers, rather than use just indexedDB = does not run on webkit = impractical |
| 08:41 | <tantek> | that seems like pretty obvious logic |
| 08:41 | <odinho> | It should do the same in Opera then hopefully. |
| 08:41 | <odinho> | Well, WebKit should fix their IDB. They have an implementation, although it's old and buggy. |
| 08:42 | <hsivonen> | tantek: depends on how different the localStorages are |
| 08:42 | <tantek> | indeed |
| 08:42 | <hsivonen> | tantek: fixing the problem localStorage has in a proper way would change it to a different callback-based API |
| 08:42 | <tantek> | would be hard to answer without actually implementing the aforementioned strategy |
| 08:42 | <hsivonen> | tantek: Google search says http://blog.nparashuram.com/2012/05/introducing-indexeddb-shim-over-websql.html |
| 08:42 | <hsivonen> | (I have no idea if it works) |
| 08:43 | <tantek> | ooh shims all the way down |
| 08:43 | <tantek> | "WebSql iteself has shims implemented and this should work well over those shims too." |
| 08:43 | <tantek> | from that post |
| 08:43 | <tantek> | nice find hsivonen |
| 08:43 | <tantek> | perhaps there is hope for IndexedDB after all |
| 08:43 | <hsivonen> | tantek: if different localStorages diverge enough, we might as well call one version Web SQL Database and another IndexedDB |
| 08:44 | <tantek> | right - hence "indeed" above |
| 08:44 | <hsivonen> | tantek: anyway, intuitively, it should be easier to emulate IndexedDB over Web SQL than vice versa |
| 08:44 | <tantek> | agreed |
| 08:45 | <tantek> | I think IndexedDB has a subset of functionality |
| 08:45 | <tantek> | plus WebSQL is a dead end draft |
| 08:45 | <tantek> | so we shouldn't be encouraging anyone to code to that API |
| 08:50 | <hsivonen> | well, if we were implementing localStorage.new and WebKit was implementing localStorage.old, your practicality argument would seem to involve encouraging people to write for localStorage.old for WebKit |
| 08:50 | <hsivonen> | seems like the same situation with Web SQL |
| 08:51 | <hsivonen> | except the two APIs are separate designs instead of iterations of one design family |
| 08:57 | <tantek> | right, presumably with iterations of the same API your business logic can still remain relatively similar. two completely different APIs usually means very different business logic / maintenance - except of course if you can polyfill one with the other as already discussed. |
| 09:00 | <hsivonen> | tantek: yes, except with localStorage the problem is so fundamental that an API fix would go from sync API to async API which virtually always involves significant code structure changes to the caller |
| 09:00 | <hsivonen> | anyway, I still think prefixing would not have made the localStorage situation better |
| 09:01 | <hsivonen> | so as far as historical datapoints go, I count localStorage as a Real Problem case against which prefixing would have been useless |
| 09:01 | <tantek> | sure, we could have always introduced asyncLocalStorage instead |
| 09:01 | <hsivonen> | indeed |
| 09:01 | <tantek> | and left the existing one in place |
| 09:02 | <tantek> | the so-called "new names are easy" argument per the IETF RFC that obsoleted x- prefixes |
| 09:02 | <tantek> | I'm sure that's made the rounds here right? |
| 09:02 | <hsivonen> | I've noticed the RFC |
| 09:02 | <tantek> | worth reading the whole thing |
| 09:03 | <hsivonen> | kudos to Peter St.Andre for getting it published at the IETF which is generally more change-averse than the W3C |
| 09:03 | <tantek> | indeed - it came as quite a surprise |
| 09:03 | <annevk> | hsivonen: did anything came out of https://twitter.com/BrendanEich/status/223802905596133376 ? |
| 09:03 | <tantek> | impressively so |
| 09:03 | <hsivonen> | annevk: I don't know. |
| 09:04 | <hsivonen> | annevk: a couple of B2G APIs have been unprefixed lately, IIRC, but I don't know if that should be credited to Brendan's influence |
| 09:04 | <tantek> | annevk - do you mean aliasing -moz-opacity, or unprefixing future JS APIs? |
| 09:05 | <annevk> | I was looking for some kind of statement |
| 09:07 | <hsivonen> | was there a statement about CSS unprefixing at Mozilla, either? I saw dbaron's policy proposal and then code action--but not a statement of the policy getting adopted |
| 09:07 | <hsivonen> | (hooray for code action!) |
| 09:08 | <tantek> | hsivonen - I believe dbaron's policy proposal has been brought to CSSWG where we can further argue it there |
| 09:08 | <tantek> | it's a bigger win if we can alter CSSWG policy than just Mozilla policy |
| 09:08 | <tantek> | that's our current path of "statement" / "policy" change |
| 09:08 | <annevk> | I wonder why file URLs have a different code path from other hierarchical URLs in Chrome/Gecko |
| 09:09 | <hsivonen> | tantek: yes, but I thought it was supposed to get adopted by each vendor (routing around the CSS WG) |
| 09:09 | <hsivonen> | "yes" as in bigger win *if* the CSSWG adopts it |
| 09:10 | <hsivonen> | which I, admittedly as a CSSWG outsider, see as a big "if" |
| 09:10 | <tantek> | hsivonen - well, we got adoption in the specific cases of TAA |
| 09:10 | <tantek> | in the CSSWG |
| 09:10 | <tantek> | hsivonen - that's fine (to see it as a big if) |
| 09:10 | <tantek> | that's dbaron and my job to make the big if actually succeed |
| 09:11 | <hsivonen> | ok |
| 09:11 | <tantek> | San Diego should be interesting |
| 09:11 | <hsivonen> | CSSWG meeting in San Diego before TPAC? |
| 09:12 | <tantek> | august |
| 09:12 | <hsivonen> | ok |
| 09:13 | <annevk> | contrast e.g. ws:test and file:test |
| 09:14 | <annevk> | and file://test/ and file:///test/ vs ws:///test/ |
| 09:15 | <hsivonen> | who is responsible for cloning https://www.w3.org/Bugs/Public/show_bug.cgi?id=18367 and the like into the WHATWG component? |
| 09:15 | <annevk> | hsivonen: a script Hixie wrote |
| 09:15 | <hsivonen> | (I think cloning bugs is bad compared to having flags for tracking snapshots) |
| 09:16 | <hsivonen> | (Mozilla doesn't close bugs for ESR but tracks ESR status using flags that are secondary to the main bug FIXED status) |
| 09:18 | <hsivonen> | s/close/clone/ |
| 09:18 | <annevk> | ESR? |
| 09:19 | <hsivonen> | annevk: Extended Support Release |
| 09:19 | <hsivonen> | annevk: the enterprise edition of Firefox |
| 09:20 | <odinho> | So like LTS only a NIH name? :D |
| 09:20 | <hsivonen> | odinho: yeah |
| 09:21 | <odinho> | Cool. Wonder what we should call it if we ever do something like that. Need to make some more acronyms! |
| 09:21 | <hsivonen> | Mozilla's "Extended" is less extended than Canonical's "Long" is long |
| 09:23 | <hsivonen> | "Extended" is roughly one fifth of "Long" |
| 09:23 | <odinho> | Yeah, 12.04 LTS will be there a looong time, -- I'm in the process of upgrading all servers to it :] |
| 09:23 | <odinho> | 12.04 LTS is ELTS - Extra long term support :P |
| 09:32 | <AryehGregor> | hsivonen, in the HTML5/HTML-LS case, the specs are edited by different people who might conceivably decide on entirely different resolutions, so I don't think the Mozilla way would work well. |
| 09:33 | <tantek> | AryehGregor - we don't know who the HTML5 editor(s) will be so it's pointless to make such suppositions. |
| 09:33 | <tantek> | They might just take all upstream bugfixes for example |
| 09:34 | <tantek> | I'd prefer to give the new HTML5 editor(s) a chance to prove themselves. |
| 09:34 | <AryehGregor> | tantek, in that case, there's no point in splitting the bugs, no. |
| 09:34 | <AryehGregor> | But I don't think the Mozilla-style solution is *necessarily* workable. |
| 09:34 | <tantek> | there's always risks |
| 09:34 | <tantek> | if it weren't for people in general doing the right thing, open standards would fail, and open source would fail |
| 09:35 | <tantek> | so it's pointless to worry about worst cases of human behavior like that, or rather to do so and still try to participate. |
| 09:35 | <tantek> | (in open standards and open source) |
| 09:41 | <AryehGregor> | All I'm saying is that since the HTML5 editor will be perfectly entitled to resolve bugs differently from the HTML editor, we can't give them the same bugs in the same fashion as is done in Mozilla, where entirely different resolutions are not accepted for older versions. |
| 09:41 | <AryehGregor> | The workflow doesn't work. |
| 09:41 | <AryehGregor> | If the HTML5 editor commits to only backport HTML changes, then no, there's no reason to have separate bugs, but nothing guarantees that will be the case (unlike at Mozilla). |
| 09:44 | <Bonob0h> | salut, y a t il des francophones dans le coin ? |
| 09:46 | <hsivonen> | For expectations, it would help if the HTML WG chairs characterized the WHATCG spec as the trunk instead of characterizing it as one possible proposal for HTML.next. |
| 09:46 | <hsivonen> | AryehGregor: I wish the HTML5 editor ends up backporting fixes in which case bug cloning will have been unnecessary. |
| 09:46 | <AryehGregor> | hsivonen, yeah, that would be nice. |
| 09:47 | <hsivonen> | making completely different resolutions would be like the XHTML2 WG all over again |
| 09:48 | <tantek> | hsivonen - that's optimistic |
| 09:48 | <tantek> | xhtml2 wg was much worse than that |
| 09:48 | <Stevef_> | i also hope that implementation bugs are fixed as per HTML, and think that will occur. I don't think that all bugs should be accepted though |
| 09:49 | <AryehGregor> | Yeah, there should be some things that aren't backported to HTML5, just as with any kind of snapshot-thing. |
| 09:49 | <tantek> | I actually expect to see features *dropped* from HTML5 as it makes its way through CR and test show no one implements things, or not interoperably so. |
| 09:50 | <AryehGregor> | Yes, that's likely given W3C Process. |
| 09:50 | <AryehGregor> | In particular, if large bugs are found in a particular feature, it seems likely that the feature might be dropped instead of fixed. |
| 09:50 | <AryehGregor> | That's fine, it's a subset spec anyway. |
| 09:50 | <tantek> | indeed |
| 09:50 | <Stevef_> | the only time there would be disagreement on implementation stuff is impementers don't agree right? |
| 09:51 | <AryehGregor> | Well, you'd hope so. |
| 09:51 | <tantek> | it will be interesting to see how the whatwg spec evolves to incorporate (or not) such feature cutting |
| 09:51 | <AryehGregor> | There have been and are W3C specs that just ignore implementations entirely. |
| 09:51 | <tantek> | feature dumping that is |
| 09:51 | <tantek> | aryehgregor - unfortunately so |
| 09:51 | <AryehGregor> | I.e., they spec something that implementers have said they don't want to implement. |
| 09:51 | <AryehGregor> | Hopefully that won't happen again here. |
| 09:52 | <tantek> | AryehGregor - we could use more folks with that perspective in HTMLWG |
| 09:52 | <Stevef_> | tantek: if there is stuff that is not being implemented they shoudn't hang around in any specs should they? |
| 09:52 | <tantek> | and every other HTMLWG |
| 09:52 | <hsivonen> | dropping features is to be expected if the HTML WG adheres to the interop reqs of the Process like the CSSWG and doesn't get sucked into a political vortex where interop matters less |
| 09:52 | <AryehGregor> | Although it's true that W3C Process these days makes it impossible to get to REC if you don't have two implementations. |
| 09:52 | <tantek> | Stevef_ different specs may have different "experimentation" tolerances |
| 09:52 | <hsivonen> | (I sure hope it doesn't get sucked into that political vortex) |
| 09:52 | <tantek> | CR, especially upon exit has a very low tolerance for experimental features |
| 09:53 | <Stevef_> | tantek: right, but exit won't happen for years and years no? |
| 09:53 | <hsivonen> | (the sort of place where RDFa seems to be with headed or already is) |
| 09:53 | <Ms2ger> | AryehGregor, that might be true for the Process as written; I doubt it's true for the Process as actually enforces |
| 09:53 | <Ms2ger> | *enforced |
| 09:54 | <tantek> | stevef_ depends on how long the WG sets for the CR period |
| 09:54 | <tantek> | and whether the WG wants to bounce between LC and CR |
| 09:54 | <AryehGregor> | Ms2ger, if there are people in the WG who will call people on it . . . |
| 09:54 | <annevk> | Ms2ger: AryehGregor: I don't think that's actually in the Process or enforced |
| 09:54 | <hsivonen> | Ms2ger: so far the HTML WG Chairs have almost enforced the process too much... |
| 09:54 | <Stevef_> | and if no interop exists on features after years and years and no indication that it will from implementers then... |
| 09:54 | <annevk> | Ms2ger: AryehGregor: it's just good practice |
| 09:54 | <AryehGregor> | annevk, IIRC, it is in the process. |
| 09:54 | AryehGregor | looks |
| 09:54 | <Ms2ger> | (In general, not particularly for the HTMLWG) |
| 09:54 | <AryehGregor> | Oh, it's a "should", I guess. |
| 09:54 | <AryehGregor> | http://www.w3.org/2005/10/Process-20051014/tr.html#cfr |
| 09:55 | <AryehGregor> | "each feature of the technical report has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature. If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director may accept to Call for Review of a Proposed Recommendation even without adequate implementation experience" |
| 09:55 | <AryehGregor> | So it's not a hard rule. |
| 09:56 | <annevk> | and many on the W3C Team will tell you that two implementations of a feature means two implementations passing a testcase |
| 09:56 | <tantek> | no it's something that requires WG members to push for it |
| 09:56 | <tantek> | (regarding not a hard rule) |
| 09:57 | <annevk> | fortunately some groups have pursued higher standards |
| 09:57 | <tantek> | and other specs are fiction |
| 10:01 | <hsivonen> | Stevef_: do you happen to recall how (according to Hixie) the API mapping doc contradicts HTML-LS? |
| 10:02 | <hsivonen> | Stevef_: does your alt guidance doc have any WAI consensus behind it? (My vague recollection is that I've seen some misgiving from the WAI about publishing it; maybe I should search the archives.) |
| 10:03 | <Stevef_> | hsivonen: no that information was never provided, to my knowledge bugs filed against the spec would help resolve differences or at least provide clarification on why there are differnces |
| 10:03 | <Stevef_> | hsivonen: FYI the API guide is currently non normative |
| 10:04 | <hsivonen> | Stevef_: anyway, to your earlier question, http://www.paciellogroup.com/blog/2012/07/w3c-html-and-whatwg-html-split-affect-on-html-accessibility/ looks pretty accurate on the basis of facts but some of the facts taking without additional info are misleading on their own |
| 10:05 | <Stevef_> | hsivonen: the WAI have provided feedback on the alt doc and have no major issues with what it contains, but they are pushing to have it moved out of HTML WG into WAI |
| 10:05 | <hsivonen> | Stevef_: specifically, even though the API mapping guide is nominally published through the HTML WG, it is really developed by a separate small group of interested people and isn't something that the HTML WG really pays attention to |
| 10:05 | <Stevef_> | hsivonen: OK am happy to clarify any particular points on the post |
| 10:06 | <hsivonen> | Stevef_: so the fact that the API doc work is happening under the W3C umbrella doesn't really say much about W3C HTML5 vs. WHATWG HTML-LS. |
| 10:06 | <hsivonen> | Stevef_: any more than some other related doc work happening at the W3C |
| 10:07 | <Stevef_> | hsivonen: its in the HTML WG because that I think is the right place for it as its subject is HTML and its an open (in w3c terms) working group |
| 10:07 | <hsivonen> | Stevef_: the refusal to link to it from the WHATWG spec says *something* about *something* though |
| 10:07 | <hsivonen> | Stevef_: I'm not suggesting it's in a wrong place |
| 10:08 | <hsivonen> | Stevef_: I'm just saying that the API doc nominally being in the HTML WG is neither a merit nor a dismerit for W3C HTML5 and is neither proof nor non-proof of the general interest in the topic at the HTML WG |
| 10:09 | <Stevef_> | hsivonen: as i said to anne yesterday, there has gernerally been no input on the API guide from the WHATWG side, and only negative non actionable feedback from hixie in particular |
| 10:09 | <hsivonen> | Stevef_: FWIW, I think I've said occasional positive things about the API doc and haven't been negative about it, but then it would be correct not to count me as representing the WHATWG |
| 10:10 | <Stevef_> | hsivonen: meanwhile we have had direct input from browser acc engineers |
| 10:11 | <hsivonen> | Stevef_: the lack of WHATWG input is probably explained by the lack of detailed knowledge of browser accessibility API mapping implementations among the people you consider to be "the WHATWG side" |
| 10:11 | <Stevef_> | hsivonen: i am happy to get constructive feedback and bugs on the doc from anyone |
| 10:12 | <Bonob0h> | personne ne parle français ? |
| 10:13 | <Stevef_> | hsivonen: sure, but what little has been said of the doc has not been useful or constructive |
| 10:13 | <hsivonen> | Bonob0h: typiquement, on parle anglais ici |
| 10:14 | <Bonob0h> | donc si on ne parle pas anglais on a pas le droit a la parole ! tout le web doit parler anglais ! bravo ! |
| 10:14 | <Bonob0h> | et bien sur aucun channel dans différentes langues !!! |
| 10:15 | <annevk> | zou behoorlijk lastig worden als we allemaal in onze eigen taal gaan chatten |
| 10:15 | <hsivonen> | Bonob0h: personne n'a dit que vous n'avez pas le droit a la parole |
| 10:15 | <Bonob0h> | j'espère que la chine va dominer le monde ! et que bientot tous les anglophone devront parler et coder en mandarin |
| 10:16 | <AryehGregor> | צריכים לדבר בעברית! |
| 10:16 | <Stevef_> | hsivonen: and surprisingly (to me) the information in it is being used to guide implementations in a number of browsers especially for new features |
| 10:16 | <Ms2ger> | AryehGregor, hey, other scripts aren't fair ;) |
| 10:17 | <hsivonen> | Stevef_: as I said on Twitter (and, I belive, at TPAC two years ago), I think it's useful work |
| 10:17 | <AryehGregor> | Ms2ger, fine. |
| 10:17 | <AryehGregor> | Tzrichim ledaber be'ivrit! |
| 10:17 | <annevk> | Stevef_: if you got the impression from me that I did not think API mapping was useful, sorry about that; I do think it's useful |
| 10:17 | <annevk> | Stevef_: just tried to explain why Hixie might have problems with some of the content |
| 10:18 | <hsivonen> | Stevef_: anyway, getting feedback and implementations from browser accessibility engineers is a better way to proceed that fighting about the link with Hixie. :-/ |
| 10:18 | <hsivonen> | s/that/than/ |
| 10:18 | <Ms2ger> | <tabatkins> I [�] successfully blocked an attempted rename recently. |
| 10:19 | <Ms2ger> | Jury / WG was still out on that last time I checked |
| 10:19 | <annevk> | Stevef_: but the simplest way forward here seems to be to continue demonstrating you do a better job and then when Hixie gets to looking at that particular part of HTML again he'll adjust the spec accordingly |
| 10:19 | hsivonen | thinks angle direction changes are more confusing that renames |
| 10:19 | <hsivonen> | s/that/than/ |
| 10:19 | <annevk> | Stevef_: not much more needed than demonstrating implementors are actually following a different specification |
| 10:20 | hsivonen | has trouble with "than" today |
| 10:20 | <AryehGregor> | Yeah, one thing you can say for the WHATWG -- if you have implementers on your side, you win no matter what. |
| 10:20 | <Stevef_> | hsivonen: annevk: we know its incomplete, there is a lot of stuff that still needs to be added, but for the quite numerous features that are not covered by the ARIA imeplementation guide it is the ONLY document that provides info on how browsers do or should implement HTML acc across paltforms and APIs |
| 10:21 | <AryehGregor> | Well, I didn't ever convince Hixie to align with ES for numeric parsing, I don't think. |
| 10:22 | <AryehGregor> | But we don't have real interop there right now anyway. |
| 10:22 | <Stevef_> | hsivonen: annevk:it is also helping to work out what new stuff needs to be aded to ARIA (1.1), such as roles for new HTML features that are currently not in any API |
| 10:22 | <Stevef_> | hsivoen:annevk: on link to it, sure I am like a dog with a bone sometimes, probably not my best feature |
| 10:23 | <hsivonen> | Stevef_: my point was that that's all good for the API mapping doc, but it's not a merit for W3C HTML5 relative to WHATWG HTML-LS (except for the link maybe) |
| 10:23 | <hsivonen> | Stevef_: so insinuating (on Twitter) accessibility merit of W3C HTML5 because of the API mapping doc is off the mark |
| 10:24 | <Stevef_> | hsivonen: my point was that there is more that goes on in the HTML WG than HTML5, so calls to shut it down are inflammatory and insulting to the other work going on |
| 10:25 | <hsivonen> | Stevef_: fair enough. |
| 10:26 | <hsivonen> | this may be insulting, too, but I didn't remember that the API mapping was an HTML WG deliverable |
| 10:26 | <hsivonen> | I do remember that RDFa in HTML nominally is, but it seems in practice a different group works on it |
| 10:27 | <hsivonen> | most of the ISSUE Process seems to be focused on parts branched/forked from WHATWG HTML-LS |
| 10:27 | <Stevef_> | hsivonen: and i am attempting to engage with WHATWG on the stuff I do, for example the recent draft using ARIA doc which I intend to be published as a WG deliverable (note) i sent an email to whatwg about |
| 10:28 | <Stevef_> | hsivonen: no offense taken, it is a deliverable, but not in the HTML5 timeframe |
| 10:29 | <hsivonen> | Stevef_: FWIW, I didn't retweet fantasai in agreement but in the sense "see this", since I think it's noteworthy how the sentiment is turning against trusting the W3C HTML WG to do a good job with HTML |
| 10:30 | <hsivonen> | after all, participating is unpleasant enough that people (me included) have been tuning out |
| 10:30 | <Ms2ger> | hsivonen, I thought the E in ESR was for Enterprise, not Extended? |
| 10:31 | <Stevef_> | hsivonen: all I can do is publicise work and call for feedback http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jun/0269.html |
| 10:31 | <hsivonen> | Ms2ger: it's "Extended" https://www.mozilla.org/en-US/firefox/organizations/all.html |
| 10:31 | <Ms2ger> | I stand corrected, thanks |
| 10:34 | <Stevef_> | hsivonen: re retweet OK. participation in WHATWG is not exactly seen as pleasant for many of my peers either, thus the lack of participation, despite that I have tried to bite the bullet and do it as I am interested in improving HTML as I see improvement ;-), and realize that working only in the HTML WG is not enough |
| 10:37 | <Ms2ger> | Stevef_, I guess most people on the WHATWG list don't have much experience with accessibility APIs and prefer to remain silent rather than to make uninformed comments |
| 10:37 | <hsivonen> | while I'd prefer the PP to change such that RECs wouldn't be special from the PP perspective, if we take the PP as a given, I think publishing a snapshot is a good thing from PP perspective |
| 10:37 | <hsivonen> | so I hope the HTML WG succeeds there |
| 10:37 | <Stevef_> | Ms2ger: OK |
| 10:37 | <hsivonen> | but I also hope various people who have a beef with Hixie don't take it as an opportunity to stick their stuff into what was supposed to be a snapshot |
| 10:38 | <hsivonen> | I also am quite skeptical about there being enough participation to get a snapshot done, because it's always cooler to work on new stuff than to polish old stuff for the PP's sake |
| 10:39 | <hsivonen> | (CSS 2.1 got done, but the CSS WG is exceptional at the W3C) |
| 10:39 | <Ms2ger> | hsivonen, or for any sake, really |
| 10:40 | <Ms2ger> | Also in implementations |
| 10:40 | <hsivonen> | Ms2ger: hey, I'm polishing readyState and about:blank! |
| 10:40 | <Ms2ger> | hsivonen, and I sure am glad you are :) |
| 10:41 | <Ms2ger> | Though I guess you may not be as glad about undertaking it :) |
| 10:41 | <hsivonen> | everlasting fame awaits among people who care about the readyState of XSLT output! |
| 10:45 | <Stevef_> | hsivonen: "but I also hope various people who have a beef with Hixie" I only have a persoanl beef in so much as he decides what goes into the WHATWG spec, so naturally I am going to work on the spec that I feel I have a better chance of affecting change, i don't always succeed, but i put a lot of effort, research and data collection into my efforts and think that when they are accepted they... |
| 10:45 | <Stevef_> | ...have merit |
| 10:47 | <Stevef_> | hsivonen: in particular authro conformance advice and requirments that are not dependent on browser implementers, and also aligning such with implementation (or lack of) realities that have a negative effect upon users |
| 10:50 | <Stevef_> | hsivonenL for example with the title attribute stuff, IF browsers provided input device independent access to the content I would have no problem with whats in the HTML spec, but they don't and its been that way for a long time and there is no indication that there will be a shift in current browser behaviours in a timeframe that will make the conformance requirments and advice align with reality |
| 10:53 | <Stevef_> | hsivonen: having said that IE 10 displays title attribute as a tooltip on focus, which is a start, so if other browsers follow suit at some point the HTML spec may actually provide useful advice for developers that does not lead to inaccessible content |
| 10:53 | <hsivonen> | Stevef_: displaying on keyboard focus makes sense |
| 10:53 | <hsivonen> | Stevef_: IIRC, Firefox for Android shows it for links on tap&hold. (though I'd have to test to be sure) |
| 10:54 | <Stevef_> | hsivonen: yes, which is what I have argued and written about for almost a deacade :-) |
| 10:55 | <Stevef_> | hsivoenen: but it still leaves issues for any non focusable content, such as the advice in the HTML spec to use title for short footnotes... |
| 10:56 | <hsivonen> | I think I disagree with the short footnote advice |
| 10:57 | <Stevef_> | hsivonen: I will rejoice when the day comes that browsers provide access to title attribute content so I don't constantly have to tell clients that what they are doing doesn't work for users, but that day is a way off |
| 10:59 | <Stevef_> | hsivonen: which is why I have pushed for the HTML5 spec not to include such advice as for better or worse it is a source for HTML authoring rules |
| 11:01 | <Stevef_> | anyway sorry for getting on my horse and gabbling on, as annevk siad yesterday, it one of my 'pet' issues |
| 11:01 | <hsivonen> | FWIW, I want a Gecko feature that'd force-draw a focus outline when the page has made an element not change appearance on focus but would let page-provided focus indication work if the page has customized :focus in a visible way |
| 11:01 | <hsivonen> | boilerplate * { outline: 0; } is very annoying |
| 11:02 | <Stevef_> | hsivonen: sounds good |
| 11:05 | <hsivonen> | speaking of WG dysfunctions: https://twitter.com/tabatkins/status/227683159637106689 |
| 11:10 | <Ms2ger> | I believe Bert thinks it's incompatible with pubrules |
| 11:33 | <annevk> | Ms2ger: do we want http://tools.ietf.org/html/bcp47 as BCP47 or something like LANGUAGE? |
| 11:34 | <annevk> | or maybe LANG |
| 11:34 | <Ms2ger> | Readable names are nice |
| 11:43 | <annevk> | done |
| 11:57 | <hsivonen> | hmm. the spec says meta Refresh navigates with replacement enabled. |
| 11:57 | <hsivonen> | Gecko source suggests it happens with replacement enabled only if the delay was <= 15 seconds |
| 11:57 | <hsivonen> | fun |
| 12:04 | <annevk> | spec should prolly allow for that |
| 12:08 | <annevk> | MikeSmith: I don't think we should have URL.username and URL.password |
| 12:08 | <MikeSmith> | annevk: eh? |
| 12:08 | <annevk> | MikeSmith: the whole userinfo production is considered dubious, not sure why we would expose them to APIs, abarth, arv? |
| 12:09 | <MikeSmith> | ah |
| 12:13 | <annevk> | MikeSmith: I don't expect to do much on URLs before September |
| 12:13 | <MikeSmith> | OK |
| 12:13 | <MikeSmith> | annevk: how about Notifications? |
| 12:13 | <annevk> | MikeSmith: I have a start of a JavaScript implementation of how I think the parser should be written, but it's not quite complete yet |
| 12:14 | <MikeSmith> | OK |
| 12:14 | <annevk> | maybe if I make some more time for it this week I'll try put it up on github |
| 12:14 | <annevk> | MikeSmith: Notifications I worked on today |
| 12:14 | <annevk> | MikeSmith: just posted some updates to the list |
| 12:15 | <MikeSmith> | ah OK |
| 12:15 | MikeSmith | finds exactly 500 unread messages in his mailbox |
| 12:16 | <MikeSmith> | ok the language attribute |
| 12:16 | <annevk> | yeah now they just have lang/dir |
| 12:16 | <MikeSmith> | and responded to Jonas |
| 12:17 | <MikeSmith> | so we can publish an LC draft soonish? |
| 12:17 | <annevk> | I think so |
| 12:17 | <annevk> | lets do next tuesday unless we hear anything? |
| 12:18 | <annevk> | after that I'm going to Romania |
| 12:52 | <MikeSmith> | OK let's aim for Tuesday |
| 12:52 | <MikeSmith> | annevk: ↑ |
| 12:53 | <MikeSmith> | annevk: btw we have to change your affiliation |
| 12:53 | <MikeSmith> | can we do it this week? |
| 13:04 | <hsivonen> | hmm. I predict adding <picture> to a snapshot spec after the feature freeze of the snapshow won't go well |
| 13:10 | <annevk> | MikeSmith: August 1 |
| 13:10 | <MikeSmith> | annevk: ah oK |
| 13:10 | <annevk> | MikeSmith: I'm still employed |
| 13:10 | <MikeSmith> | oh right |
| 13:10 | <MikeSmith> | OK |
| 13:38 | <hsivonen> | Does Jellybean still come with the old WebKit/Android port for apps that embed WebKit using the system APIs? |
| 13:38 | <hsivonen> | has that WebKit port improved since ICS? |
| 13:39 | <hsivonen> | that is, Dolphin on JB still uses the old Android WebKit--not the same WebKit and Chrome, right? |
| 13:54 | <odinho> | annevk: Still paying for that small ad next to your name! ;D |
| 13:55 | <annevk> | odinho: heh |
| 14:53 | AryehGregor | wonders if it's feasible to redefine NULL to be nullptr too . . . probably not |
| 14:53 | <odinho> | Hmm. |
| 14:53 | <AryehGregor> | Oh, wrong channel. |
| 14:53 | <AryehGregor> | Feh. |
| 14:54 | <odinho> | Thought so ;D |
| 14:54 | AryehGregor | always makes that mistake |
| 14:54 | <odinho> | You do, you do. |
| 14:54 | <odinho> | Just mozillaians though. |
| 14:54 | <odinho> | Don't see much webkit or opera people doing that... |
| 14:55 | Ms2ger | would be interested to see Opera people do that |
| 14:59 | <odinho> | Ms2ger: Yeah, all that secretsauce infoz! :P |
| 15:00 | <Ms2ger> | I should get myself hired by Opera for a while, just to stick my nose in all your secrets :) |
| 15:00 | <odinho> | Ms2ger: Desk next to me is free, since annevk was last visiting Oslo ;-) |
| 15:02 | <Ms2ger> | I guess I'd need to hurry if I'd wanted to get in impersonating annevk |
| 15:05 | <odinho> | Ms2ger: I'll help you :D |
| 15:07 | <annevk> | mahahaha, you want to borrow http://annevankesteren.nl/dump/opera-keycard.jpg ? although I guess that won't get you any far in the new building |
| 15:32 | <odinho> | annevk: Oh man that picture |
| 16:44 | <Hixie> | hober: fwiw, the html spec already says that if there's no control, the region represents something that isn't interactive |
| 16:56 | <hober> | Hixie: i'll make the issue-201 proposal doesn't add redundant normative text then :) |
| 16:57 | <Hixie> | as usual if there's anything you think needs adding, please post about it on the whatwg list |
| 16:58 | <Hixie> | and if it's not something you think needs adding, why are you adding it :-P |
| 16:58 | <hsivonen> | what's the deal with asking the responsive imagea cg to bring a proposal to the html wg after the feature freeze? |
| 16:58 | <Ms2ger> | Maybe they'll be asked to create a HTML6 module? |
| 17:00 | <hober> | Hixie: indeed. :) thanks for removeHitRegion; I get to make this proposal smaller as a result. |
| 17:00 | <hober> | hsivonen: my understanding is that they intend to work on "html.next" in parallel to the html5 stabilization effort. |
| 17:01 | <hsivonen> | who is "they"? |
| 17:05 | <hober> | hsivonen: the html wg |
| 17:06 | Ms2ger | wonders what will be left in the spec after the stabilization effort |
| 17:06 | <Ms2ger> | table.rows? |
| 17:07 | Ms2ger | doesn't think so, after writing http://w3c-test.org/html/tests/submission/Ms2ger/the-elements-of-html/tabular-data/the-table-element/table-rows.html |
| 17:39 | <Hixie> | ok i guess today's task will be to look at the web intents stuff, register*Handler stuff, and the proposal from mozilla |
| 17:39 | <Hixie> | and see what I can do that merges the three together in a backwards-compatible simple API and/or declarative markup that satisfies all the relevant valid use cases |
| 17:58 | <divya> | anybody knows what is the short url for whatwg multipage html spec? |
| 17:58 | <divya> | annevk: ^ |
| 17:58 | <divya> | (i know anne tweeted it or mentioned it somewhere) |
| 17:59 | <beverloo> | http://whatwg.org/html ? |
| 17:59 | <divya> | omg thnx beverloo !!!! |
| 17:59 | <beverloo> | http://whatwg.org/C works too |
| 17:59 | <beverloo> | but I prefer "html" :p |
| 17:59 | <divya> | ahaha :) |
| 17:59 | <divya> | yeah |
| 17:59 | <divya> | html is less cryptic |
| 17:59 | <divya> | what is the c for anyway? |
| 18:00 | <beverloo> | no idea |
| 18:01 | <Ms2ger> | Complete |
| 18:03 | <jgraham> | Though as a memonic seCret is better :p |
| 18:03 | <zewt> | crash your browser |
| 18:03 | <Ms2ger> | Hey, one of them is multipage |
| 18:03 | <annevk> | divya: lowercase c is single-page |
| 18:06 | <tantek> | Hixie, btw I've been checking to see what other vCard/hCard derivatives have done with "country" vs. "country-name" and it's so far been a fairly even split, with a slight leaning toward country-name. |
| 18:06 | <tantek> | e.g. PoCo used "country", but OGP used "country-name" |
| 18:08 | <tantek> | it does seem to be a common simplification to drop the "-name" part though. It's unlikely to result in an incompatibility. So I'm on the fence about it. |
| 18:09 | <tantek> | from a vocabulary design standpoint, if we adopt the principle of dropping redundant suffixes from terms similar to dropping plural suffixes, then we can proceed consistently in the instance of "country" vs. "country-name" and any future such occurences. |
| 18:12 | <TabAtkins> | Should events that fire at the document bubble or cancel? |
| 18:13 | <TabAtkins> | That's a yay/nay for each option, not a choice between two options. |
| 18:19 | <Ms2ger> | smaug____, ^ |
| 18:19 | smaug____ | doesn't understand the question |
| 18:19 | <smaug____> | it depends on the case |
| 18:20 | <smaug____> | some event bubble to the window |
| 18:20 | <smaug____> | some don't |
| 18:28 | <odinho> | smaug____: partypooper breaking the rules :P |
| 18:28 | <odinho> | Ohwell, I should really go home. |
| 18:28 | <Ms2ger> | Naah |
| 18:28 | <Ms2ger> | How do I get into the office then? |
| 18:28 | <odinho> | Ms2ger: Come tomorrow. |
| 18:28 | <Ms2ger> | Alright |
| 18:31 | <tantek> | ok I've tried to capture both the potential vocabulary design principle of dropping redundant/no-value suffixes and the specific instance of how that applies to country vs. country-name here: http://microformats.org/wiki/naming-principles#Under_Consideration |
| 18:31 | <tantek> | feel free to add more data/examples if you know of any |
| 18:36 | <annevk> | divya: you can add to your CSS spec stuff that these are the relatively simple specs ;) |
| 18:36 | <divya> | annevk: wat |
| 18:37 | <divya> | annevk: i mean why use /c or /C what is 'c' |
| 18:37 | <divya> | annevk: what is this about css spec stuff :/ |
| 18:37 | <hober> | short for "complete" |
| 18:37 | <divya> | hober: AHA. |
| 18:38 | <annevk> | divya: the ones we completed in a decade |
| 18:38 | <annevk> | or a little over a decade |
| 18:38 | <divya> | annevk: hahahah :||| |
| 18:38 | <divya> | yes |
| 18:38 | <divya> | i know right?! |
| 18:38 | <divya> | it is hilarious. |
| 18:38 | <divya> | i think it shows how irrelevant the time taken is i suppose. |
| 18:41 | <tantek> | ok, it's been pointed out on #microformats that 'country' often implies ISO country code, especially in forms (which is the broader context of this discussion - the autocomplete stuff). |
| 18:42 | <tantek> | thus I'm now leaning toward leaving 'country-name' as-is and not messing with it. |
| 18:42 | <tantek> | clarifies '-name' vs. a potential ISO country '-code' property |
| 18:42 | <tantek> | who knows, in forms, we could have both instances |
| 18:50 | <Hixie> | divya: it used to be that /html went to the WHATWG "HTML5" spec and /c went to the WHATWG "Web Applications 1.0" spec, which was called complete.html and contained everything including all the HTML stuff |
| 18:51 | <Hixie> | divya: but at some point we dropped them all and just went back to one spec, so now they all point to the same spec |
| 18:51 | <divya> | Hixie: thanks! |
| 19:00 | <TabAtkins> | smaug____: Is there a consistent guideline for whether it should bubble to window or not? |
| 19:01 | <TabAtkins> | Context is a FontFaceLoaded event, which fires when a @font-face finishes loading. |
| 19:01 | <TabAtkins> | (And gets fired at the document, since you can't access the @font-face rules from cross-origin stylesheets.) |
| 19:03 | <smaug____> | there is no guideline |
| 19:04 | <TabAtkins> | Awesome. |
| 19:37 | <Hixie> | TabAtkins: generally speaking, don't bubble things targetted at a node that isn't an Element, and make things cancelable only if they have a default action you want to be able to cancel |
| 19:41 | Hixie | mumbles something about mozilla inventing apis in their mailing lists just like everyone else |
| 19:42 | <Hixie> | (https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/o8bkwx0EtmM which i found linked to from https://wiki.mozilla.org/WebAPI/WebActivities which was linked to from a post to public-device-apis and public-web-intents) |
| 19:42 | <Ms2ger> | Yeah, the WebAPI guys are jerks like that |
| 19:45 | <tantek> | I just try to keep putting links to relevant stuff on findable (via web search) wiki pages - re: WebAPIs |
| 19:46 | <tantek> | Hixie - many folks (outside of Google) have given up on google web intents for a number of reasons (not going to bother going into details which we could spend hours on) |
| 19:46 | <Hixie> | that's a start, but i don't think we should be proposing apis by hoping people will stumble into them ;-) |
| 19:46 | <Hixie> | yeah i'm trying to work out how to merge all the various proposals here into one coherent whole |
| 19:46 | <tantek> | Hixie, what do you do when the WGs where you "should" propose them are greatly outnumbered by folks with very different priorities and timelines? |
| 19:46 | <tantek> | DAP etc. |
| 19:46 | <Hixie> | (hopefully the problems you reference are documented somewhere) |
| 19:47 | <tantek> | Good luck - the intents stuff is an every growing blob of mess. |
| 19:47 | <Hixie> | tantek: well, DAP imho is never a place to propose anything |
| 19:47 | <tantek> | well DAP is where WebAPIs were supposed to be proposed (in W3C) |
| 19:47 | <Hixie> | nah, public-webapps is the right place for web apis |
| 19:47 | <tantek> | so instead, you can find all the real-world ship-driven work here: https://wiki.mozilla.org/WebAPI/ |
| 19:47 | <Ms2ger> | And the HTML WG was where HTML was supposed to be worked on |
| 19:48 | <tantek> | maybe I should actually officially join public-webapps instead of merely being an observer then |
| 19:48 | <Hixie> | public-webapps for apis, whatwg for apis and markup, www-svg and www-math for svg and mathml, www-style for rendering, and that should be it, imho |
| 19:48 | <Hixie> | audio, webrtc, dap, intents, perf, etc, all shouldn't exist imho |
| 19:48 | <tantek> | that's a decent summary Hixie, have you put that on the WHATWG wiki somewhere? |
| 19:48 | <tantek> | e.g. in the "where do I propose something" FAQ |
| 19:48 | <Hixie> | i have not |
| 19:49 | <tantek> | seems to come up often enough |
| 19:49 | <Hixie> | the whatwg wiki says "whatwg" as "where do i propose something" |
| 19:49 | <Ms2ger> | "Create a new CG" |
| 19:49 | <Hixie> | which seems like a good first approximation to me :-) |
| 19:49 | <tantek> | so should I send ContactsAPI to WHATWG? |
| 19:49 | <tantek> | https://wiki.mozilla.org/WebAPI/ContactsAPI is another thing I edit. |
| 19:50 | <Hixie> | wtf is contacts api |
| 19:50 | <Hixie> | that should just be a js library, why would the browser support that |
| 19:53 | <gsnedders> | Hixie: Because many apps on phones want access to contacts, and having apps work cross-platform is desirable? |
| 19:55 | <Ms2ger> | Sounds like a library would work much better than an API per vendor, then |
| 20:01 | <tantek> | because it requires access to device specific storage of contacts |
| 20:01 | <tantek> | so it has to go in the platform since a library can't access that |
| 20:01 | <tantek> | you could write a library on top of ContactsAPI if you want |
| 20:02 | <tantek> | sorry Hixie - didn't mean to distract you - was just providing another example of a WebAPI - there's plenty more. |
| 20:02 | tantek | realizes previous link went to a blank page |
| 20:03 | <tantek> | ok, fixed with a redirect for posterity |
| 20:03 | <tantek> | plenty more: https://wiki.mozilla.org/WebAPI#APIs |
| 20:41 | <annevk> | TabAtkins: FontFaceLoaded event sounds wrong, events should be lowercase |
| 20:42 | <annevk> | TabAtkins: fontfaceload seems more in line with what we have thus far |
| 20:42 | <TabAtkins> | That's the name of the interface. That should be uppercase, right? |
| 20:42 | <annevk> | TabAtkins: name of the interface should end in Event |
| 20:43 | <TabAtkins> | Sorry, it does end in Event in my actual proposal. |
| 20:44 | <annevk> | but that should prolly be FontFaceEvent and the name of the event fontfaceload or some such |
| 20:44 | <annevk> | depending on what we want |
| 20:44 | <annevk> | and some API to add an @font-face to some style sheet |
| 20:58 | <annevk> | tantek: does proposing mean dropping a link or working with everyone to turn it into something? |
| 20:58 | <tantek> | annevk - I suppose it's a spectrum. |
| 20:58 | <tantek> | the more open the better |
| 20:59 | <annevk> | tantek: either way is fine as far as emailing to whatwg⊙wo goes, just curious |
| 20:59 | <tantek> | I just find email iteration tedious/inefficient, so prefer to iterate with wiki + irc links/chats until things seem fairly solid, then I'm ok with dropping a link to email just for old school's sake. |
| 20:59 | <annevk> | tantek: but it seems those APIs are primarily driven by a group at Mozilla that is not too communicative so setting expectations in such an email might be nice |
| 21:00 | <tantek> | Jonas has been pretty communicative in WebApps |
| 21:00 | <annevk> | tantek: well until this IRC channel has 1500 members you're not going to reach everyone involved in the WHATWG |
| 21:00 | <tantek> | and he's driving most of WebAPI |
| 21:00 | <Ms2ger> | Oh? |
| 21:00 | <Ms2ger> | I haven't seen much about this webapi stuff in webapps |
| 21:01 | <tantek> | annevk - in practice 1500 people don't contribute to specs. |
| 21:02 | <annevk> | tantek: that does not mean they should be ignored until things are "solid" |
| 21:03 | <tantek> | or maybe they shouldn't be spammed until things are more mature |
| 21:03 | <Ms2ger> | They subscribed for a reason |
| 21:03 | <annevk> | tantek: you mean when they can no longer influence direction? |
| 21:03 | <tantek> | anyway, see above, I find email iteration tedious/inefficient thus it's a notification system of last resort, in order to stay more productive. |
| 21:03 | <tantek> | ms2ger - who knows why people subscribe to mailing lists |
| 21:04 | <Ms2ger> | Presumably because they want to receive emails |
| 21:04 | <Ms2ger> | That's why I do it, at least |
| 21:04 | <tantek> | hah! |
| 21:06 | <tantek> | annevk - if folks want to only be on email, I'm fine treating that as "support forum" level discussion. plenty of ways to influence direction, including writing blog posts, editing wiki pages, contributing to irc discussions etc. |
| 21:06 | <tantek> | email lists generally devolve into support forum level thrashing - some may wish to receive such emails, good for them. I find them unproductive. |
| 21:07 | <tantek> | the lists/emails that is - not the people |
| 21:08 | <zewt> | no, mailing lists are the most effective communications medium we have (irc is better for quick back and forth, but less inclusive) |
| 21:10 | <Ms2ger> | I find it unfortunate that things are not discussed in a multi-vendor forum because you find that unproductive |
| 21:10 | <annevk> | pretty sure mailing list email is the one way some people keep track of standards work |
| 21:10 | <annevk> | not keeping them in the loop because you prefer some other medium seems silly |
| 21:10 | <annevk> | I did not suggest debating anything via email, just giving people a heads up and a way to participate |
| 21:10 | <annevk> | if you think that should be IRC/Wiki for now, that's fine |
| 21:10 | <annevk> | but if you don't even clue them in on where to start, they'll never get there |
| 21:10 | <tantek> | I'm aware of your opinion zewt, and we've already chosen to disagree. |
| 21:10 | <zewt> | (you're being rude; this discussion is not only for you) |
| 21:11 | <tantek> | No I'm being terse. There's a difference. And you've expressed these opinions before in IRC and we've disagreed before. No need to repeat ourselves. |
| 21:11 | <zewt> | nope; if you're going to repeat your position, then I'm going to repeat mine |
| 21:12 | <tantek> | that's an odd approach to productivity. ;) |
| 21:13 | <zewt> | hardly; you're presenting your position (presumably) because you believe there are people reading who are unaware of it, and if you're presenting your rather odd view to other people, then clearly other positions should be restated as well |
| 21:13 | <tantek> | annevk - since Jonas is leading up the WebAPI effort and in WebApps, I'll leave it to him to decide how/when to notify which groups of what. |
| 21:14 | <zewt> | (on the other hand, spending this much of your--and my--time telling me not to state my opinion is a rather odd thing to do) |
| 21:14 | <tantek> | zewt, nah, annevk and I were simply having a discussion. I don't think your meta-arguments apply. sorry. |
| 21:14 | <annevk> | tantek: he was not directing it to you in particular though and I had not seen zewt's opinion before |
| 21:14 | <annevk> | (or more likely, I forgot, I try to keep up with the logs :)) |
| 21:15 | <zewt> | (I'm not discussing whether I should state my opinion on IRC any more because it's a waste of my time; I'll continue to state my opinion when I wish, thanks) |
| 21:15 | <tantek> | feel free state your opinion as much as you like. I'm just choosing to simply disagree and not both rehashing the arguments. |
| 21:15 | <annevk> | tantek: anyway, WHATWG and W3C's main medium of communication is the mailing lists, if you avoid them prepare for some trouble |
| 21:15 | <TabAtkins> | annevk: I have no idea how to design events well. Ms2ger just suggested some improvements to the design as well. |
| 21:15 | <tantek> | annevk - we're slowly getting W3C to use wikis more |
| 21:16 | <tantek> | it's a transition, it'll happen. |
| 21:16 | <annevk> | still waiting for RDF |
| 21:16 | <tantek> | is that like waiting to exhale? |
| 21:17 | <annevk> | heh |
| 21:17 | <tantek> | annevk - yes, you can find a bunch in the irc archives by searching for "email" and "support forum" |
| 21:17 | <Hixie> | gsnedders, tantek: seems pretty clear to me that "contacts" as a concept tied to a device is yesterday's tech |
| 21:17 | <tantek> | Hixie, yesterday's tech is today's/tomorrow's tech in parts of the world |
| 21:18 | <tantek> | plus, as long as all the contact sync services keep screwing things up (whether iCloud, or Google contacts), contacts tied to a device will remain relevant |
| 21:18 | <tantek> | since no one has made anything better actually work reliably |
| 21:18 | <annevk> | the WHATWG Wiki is frequently used too, but not without mailing list discussion to make the rest of the group aware of it |
| 21:18 | <Hixie> | beg to differ but ok :-) |
| 21:19 | <tantek> | Hixie, which perfect contact syncing service do you use? |
| 21:19 | <annevk> | contacts tied to a device? |
| 21:19 | <annevk> | who would want that? |
| 21:19 | <tantek> | people that buy the phones apparently |
| 21:19 | <tantek> | and Macs |
| 21:19 | <Hixie> | tantek: i wouldn't use syncing. i would just use cloud contacts only. |
| 21:19 | <tantek> | and PCs |
| 21:19 | <tantek> | Hixie - which "cloud" contacts then? and do you not do anything with contacts offline? |
| 21:19 | <Hixie> | tantek: my approach to phones is the same as my approach to laptops: the hardware is just a dumb terminal |
| 21:19 | <annevk> | tantek: not sure if that means they really want it |
| 21:19 | <tantek> | right, the use-case is offline. |
| 21:20 | <tantek> | we have whole APIs for that last time I checked |
| 21:20 | <annevk> | tantek: cause I'm pretty sure that if the hardware burns in a fire they'd still like their contacts on the next phone they buy |
| 21:20 | <Hixie> | tantek: my contacts live in g+, personally, but google alone has at least three different cloud contacts systems all of which i find work fine :-) |
| 21:20 | <tantek> | nevermind contacts in particular |
| 21:20 | <Hixie> | offline is for when i sleep |
| 21:20 | <tantek> | Hixie - I know highly technical google employees who have had problems with Google's various cloud contacts systems losing data. |
| 21:20 | <annevk> | Hixie: no sleep monitor? :p |
| 21:20 | <tantek> | Same with Apple employees and iCloud etc. |
| 21:21 | <tantek> | they all suck |
| 21:21 | <Hixie> | i know highly technical people who have had problems with their devices losing data, what's your point? :-P |
| 21:21 | <tantek> | less so |
| 21:21 | <annevk> | or whose phone gets water damage :p |
| 21:21 | <tantek> | the people I'm talking about found their contacts became much more randomly lossy when using syncing/cloud services |
| 21:21 | <Hixie> | this is all anecdotal and as such pretty worthless |
| 21:22 | <annevk> | tantek: if you don't configure your phone correctly that can happen |
| 21:22 | <annevk> | tantek: like if creating new contacts still creates them on the device, as is the silly default on iOS |
| 21:22 | <tantek> | well it's anecdotal enough for myself and many others to believe that we're not quite at that bright and shiny cloud future yet, and who knows if we will ever be |
| 21:23 | <Ms2ger> | annevk, sometimes water damage caused by a competitor pushing them into a lake? :) |
| 21:23 | <Hixie> | ditto but vice versa :-) |
| 21:23 | <tantek> | right, blame the user instead of the defaults. that always works. :P |
| 21:23 | <annevk> | I blamed the defaults? |
| 21:24 | <annevk> | oh well, all short term issues |
| 21:25 | <annevk> | you don't want the situation where you create a contact on your phone and it's not available on your laptop the same minute |
| 21:25 | <Hixie> | hear hear |
| 21:25 | <annevk> | or where you drop your phone in the water and you lose 200 contacts |
| 21:25 | <annevk> | that's last decade problems |
| 21:25 | <Hixie> | or where you add a contact to your tablet and it's not on your phone an hour later |
| 21:26 | <tantek> | people still have these problems yes |
| 21:26 | <Hixie> | i haven't had those problems in years |
| 21:26 | <tantek> | especially people with lots of (frequently changing) contacts |
| 21:26 | <tantek> | and who add/delete them from different devices etc. |
| 21:26 | <tantek> | Hixie - you just said you don't use sync |
| 21:26 | <tantek> | s |
| 21:26 | <tantek> | o |
| 21:26 | <Hixie> | right |
| 21:26 | <Hixie> | i use cloud |
| 21:26 | <Hixie> | sync is dumb |
| 21:26 | <tantek> | naturally, you wouldn't |
| 21:26 | <tantek> | unless you want offline |
| 21:26 | <Hixie> | sync is a bandaid |
| 21:27 | <Hixie> | offline works fine too, just cache it |
| 21:27 | <tantek> | things seem to be moving more in the sync direction, e.g. dvcs, hg, github are more of a "sync" approach than central cloud server approach (over cvs, svn etc.) |
| 21:27 | <tantek> | offline doesn't work when you add/delete contacts while offline |
| 21:28 | <tantek> | because then you need to... |
| 21:28 | <tantek> | s |
| 21:28 | <tantek> | y |
| 21:28 | <tantek> | n |
| 21:28 | <tantek> | c |
| 21:28 | <Hixie> | i'm going to go back to working out how to add intents to the spec, as this conversation is going nowhere :-) |
| 21:29 | <tantek> | no, we're not going to refigure out syncing, that's for sure. but at least it's a much more developed problem space than intents. good luck. |
| 21:35 | <TabAtkins> | I love how dramatic tantek's weird letter-per-line problem is sometimes. |
| 21:35 | <dglazkov> | d |
| 21:36 | <dglazkov> | r |
| 21:36 | <dglazkov> | a |
| 21:36 | <dglazkov> | m |
| 21:36 | <dglazkov> | a |
| 21:36 | <annevk> | TabAtkins: what's wrong with using null? |
| 21:37 | <annevk> | TabAtkins: also, the dictionary needs to inherit from EventInit |
| 21:37 | <TabAtkins> | annevk: I dunno. It's weird? |
| 21:37 | <annevk> | TabAtkins: it would be pretty consistent with most other APIs |
| 21:38 | <annevk> | TabAtkins: although maybe just using the empty string here is enough |
| 21:38 | <tantek> | TabAtkins LOL |
| 21:38 | <Ms2ger> | annevk, I said that :) |
| 21:38 | <TabAtkins> | Do DOM APIs just use null because IDL didn't allow them to use undefined? |
| 21:39 | <TabAtkins> | JS APIs, with few exceptions, use undefined and null properly for their separate things. |
| 21:39 | <Ms2ger> | What's undefined for here? |
| 21:40 | <TabAtkins> | A property that doesn't exist. |
| 21:40 | <TabAtkins> | Unfortunately, you can't *actually* make attributes exist only conditionally, but having them return undefined is nearly functionally identical. |
| 21:41 | <Ms2ger> | Oh, if the property isn't present in the @font-face rule? |
| 21:41 | <TabAtkins> | Yeah, exactly. |
| 21:41 | <Ms2ger> | null sounds good |
| 21:42 | <annevk> | nn |
| 21:42 | <TabAtkins> | Why do you think so? |
| 21:43 | <TabAtkins> | Ms2ger: annevk: Can you put this advice and requirements for designing new Event subtypes into the dom core spec? |
| 21:43 | <hober> | which one is better / worth posting? http://www.quickmeme.com/meme/3q7quj/ http://www.quickmeme.com/meme/3q7qvo/ |
| 21:44 | <Ms2ger> | http://wiki.whatwg.org/wiki/Howto_spec#Events_implementing_their_own_interface ? |
| 21:44 | <TabAtkins> | hober: Second, but s/it's/i call it/ |
| 21:46 | <TabAtkins> | Ms2ger: Ah, didn't realize that existed. That doesn't seem to contain all of the advice you've given. anne said that my init dict should inherit from EventInit as well. |
| 21:46 | <Ms2ger> | I said that too :) |
| 21:46 | <Ms2ger> | But it's a wiki, feel free to add that :) |
| 21:49 | <TabAtkins> | I'd have to log into the whatwg wiki, then. |
| 21:50 | <TabAtkins> | So, the policy is to define the interface for a group of events, and then define specific events by different 'type' values? |
| 21:51 | <Hixie> | define an interface (or preferred, use an existing interface if there is one) for each event that needs a particular set of data sent with the event |
| 21:51 | <Hixie> | most events don't need any data and can just use Event |
| 21:51 | <Hixie> | (the HTML spec has many examples if you want to crib from that) |
| 21:52 | <TabAtkins> | The html spec no longer has the event index. |
| 21:52 | <Hixie> | search for [Init : Event] |
| 21:52 | <Hixie> | or [eventInit] |
| 21:52 | <Ms2ger> | Interface / type are orthogonal, really |
| 21:53 | <Hixie> | btw you can make a property not existing in WebIDL, just define it as a named property |
| 21:53 | <Hixie> | and then say when it's in the list of supported property names or not |
| 21:53 | <Hixie> | pretty unusual and ugly though |
| 21:54 | <TabAtkins> | heycam just now said that's okay. ^_^ |
| 21:54 | <Hixie> | generally speaking you want the property to be present so you can set it |
| 21:54 | <Ms2ger> | Matches how those are usually represented in CSSOM |
| 21:54 | <Hixie> | a property being present doesn't mean the underlying field is present |
| 21:55 | <Hixie> | it's pretty standard in apis to expose all the possible fields and have a value that means "no value", namely, null |
| 21:55 | <Hixie> | "undefined" is more of a JS thing meaning "this property doesn't exist" |
| 21:55 | <Hixie> | really only applicable where other languages would refuse to compile :-) |
| 21:56 | <zewt> | well, i like how Lua does it; there's no distinction between a nil item in a dictionary and not existing |
| 21:57 | <zewt> | setting a value to nil is how you remove it from a dictionary |
| 22:02 | <TabAtkins> | Ms2ger: Why, in the how2spec example, does "type" show up both as the first argument to the constructor, and in the init dictionary? |
| 22:03 | <Ms2ger> | Wait, type in the dictionary? |
| 22:03 | <Ms2ger> | Sounds like a bug |
| 22:05 | <TabAtkins> | Okay, cool. |
| 22:06 | <TabAtkins> | Is the "type" in the attributes a bug too, since it should be inheriting that from Event already? |
| 22:08 | <Hixie> | what's the url to this page so i can go clean it up |
| 22:12 | <TabAtkins> | http://wiki.whatwg.org/wiki/Howto_spec#Events_implementing_their_own_interface |
| 22:13 | <TabAtkins> | (Damn adobe network temporarily drops about every 20 minutes.) |
| 22:14 | <Hixie> | ah, i think whoever wrote that just got confused and used "type" because they forgot about Event.type |
| 22:15 | <Hixie> | it's not meant to be related |
| 22:15 | <Hixie> | reload now |
| 22:16 | <Hixie> | the event handler stuff is out of date |
| 22:16 | <Hixie> | let me fix that too |
| 22:18 | <gsnedders> | Hixie: Tied to a device isn't the relevant point. It's about having a centralized store for contacts — it doesn't matter whether the contacts API works by delegating to some web service or whether it stores it on the device directly |
| 22:19 | <Hixie> | should just be implemented as a web service, imho |
| 22:19 | <Hixie> | possibly delegated using something like intents |
| 22:19 | <gsnedders> | But what web service? |
| 22:19 | <gsnedders> | The point is to have prefs set in one place, across the device, that can control where the prefs are stored. |
| 22:19 | <TabAtkins> | Hixie: Thanks for the update. Much less confusing now. ^_^ |
| 22:20 | <Hixie> | TabAtkins: updated the next bit too |
| 22:20 | <TabAtkins> | Okay, so even if I plan to have only a single event in this category, I still need to have a type attribute? |
| 22:21 | <Hixie> | there's no type attribute |
| 22:21 | <Hixie> | what do you mean |
| 22:21 | <Hixie> | i'm confused |
| 22:21 | <Hixie> | what? |
| 22:21 | <TabAtkins> | So, like "new FontFaceEvent('load')" rather than "new FontFaceLoadEvent()" |
| 22:21 | <Hixie> | oh, yes, because anyone can create an event that uses this interface |
| 22:21 | <Hixie> | the Event-inheriting interface and the event type are entirely orthogonal |
| 22:22 | <Hixie> | gsnedders: imho a Contacts API should define a common API mediated over something like MessagePorts and initiated via something like intents, which both the OS and any Web sites can offer to implement and provide |
| 22:22 | <TabAtkins> | Okay, so we're back to what I was trying to say, that the interface defines a group of events, with type used to distinguish specifically which event from the group is being sent. |
| 22:22 | <Hixie> | gsnedders: and the web browser doesn't need to know anything about it |
| 22:23 | <Hixie> | TabAtkins: more or less. pedantically, the interface defines a set of fields that events can use, there's no formal grouping of events into event types. |
| 22:23 | gsnedders | knows little of web intents |
| 22:23 | <TabAtkins> | Right. Okay, that makes sense then. |
| 22:23 | <Hixie> | TabAtkins: and when you fire an event, you pick the interface it should use. |
| 22:23 | <Hixie> | TabAtkins: and the event type name |
