| 00:37 | <hober> | does anyone know where the original (no text) image in http://w3cmemes.tumblr.com/post/22670112919 came from? |
| 00:39 | <hober> | nvm, found it. |
| 07:04 | <zcorpan> | web-apps-tracker gives 500 :-( |
| 07:07 | <jgraham> | annevk is away |
| 08:16 | <zcorpan> | Hixie: that's one ugly fingerprint image |
| 08:36 | <zcorpan> | Hixie: how about http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1697 |
| 09:14 | <jgraham> | zcorpan: Write that all by hand in the live dom viewer? ;) |
| 09:15 | <zcorpan> | read the comments :-P |
| 09:39 | <jgraham> | Didn't roc have a blogpost defining what makes something part of the open web? |
| 11:04 | <odinho> | Anyone want to talk IndexedDB? createIndex and "" keyPath, specifically. |
| 11:05 | <odinho> | This channel has not typically been very good on idb talk though :-/ Maybe I should try #webapps too before going to teh emailz. |
| 11:07 | <jgraham> | odinho: Since si fails to tab complete "sicking" I doubt anyone wants to discuss IndexedDB :p |
| 11:07 | <odinho> | jgraham: Yeah, he's more often in webapps though, he left there some time ago. He should be available in european work hours if you ask me! |
| 11:09 | <jgraham> | Convinve him that california doesn't have enough pickled herring and that he should move back here :) |
| 11:42 | <jgraham> | Does chrome really have no better UI for redisabling popups on a domain where you previously allowed them than editing the config file by hand? |
| 13:08 | <hsivonen_> | do I read correctly that there's a FO against not letting keyboard focus for sighted users move into @hidden subtrees? |
| 13:10 | <hsivonen> | oh, the FO is against letting focus go into the @hidden subtree |
| 13:50 | <Stevef_> | hsivonen:focus doesn't move into a @hidden subtree as far as I know |
| 13:52 | <hsivonen> | Stevef_: with the prevailing CP applied? in screenreader case or in visual+keyboard case? |
| 13:53 | <Stevef_> | hsivonen: in general, I don't understand the effects of the CP |
| 13:59 | <Stevef_> | hsivonen:either @hidden subtree is hidden from everyone so it cannot be navigated or its not so it can be navigated. when an image references a link using aria-describebdby it does not make the link focusable, it adds a default accessible action to the visible image, so that the link can be navigated to. that is how it works in the only implementation we have (firefox) |
| 14:00 | <Stevef_> | hsivonen: FYI not arguing merits of any CP btw |
| 14:01 | <Stevef_> | hsivonen: the whole thing has been bent out of shape me thinks |
| 14:02 | <Stevef_> | how it works in firefox: http://www.paciellogroup.com/blog/2012/05/firefox-14-image-long-description-via-link-using-aria-describedby/ |
| 14:03 | <Stevef_> | not a lot of use unless implemented across browsers though, same issue as longdesc |
| 14:13 | <hsivonen> | Stevef_: oh so with @hidden, it becomes a verbose and indirect equivalent of longdesc? |
| 14:14 | <hsivonen> | what happen is aria-descibedby points to an ancestor of the <a> instead of the <a> itself? |
| 14:14 | <hsivonen> | *happens |
| 14:15 | <Stevef_> | hsivonen: yes, in firefox usese same default action exposed for longdesc, note the link does not need to be hidden for it to work |
| 14:16 | <hsivonen> | yeah, the non-hidden case makes sense and the @hidden case only as a sidekick of the non-@hidden case |
| 14:16 | <hsivonen> | the @hidden case alone wouldn't be much of an improvement |
| 14:16 | <Stevef_> | hsivonen: the acc description is the text in the container element, it must directly reference a link AFAIK for the default action to be exposed |
| 14:17 | <hsivonen> | ok |
| 14:18 | <Stevef_> | hsivonen: i may suggest its use in the non hidden case, but the hidden case is well 'hidden' same as longdesc not a lot of use unless it is supported across the board, so would have to provided a visible link anyway... |
| 14:20 | <hsivonen> | Stevef_: the prevailing CP is broader than the Firefox feature you described |
| 14:20 | <hsivonen> | Stevef_: one could even argue the Firefox behavior is slightly wrong under the prevailing CP |
| 14:21 | <hsivonen> | I guess I will let other people debate it now that I see the difference. Thanks. |
| 14:21 | <Stevef_> | hsivonen: I do not see a use case for the exposing of lots of hidden content to AT only |
| 14:22 | <Stevef_> | hsivonen: I am unclear about any of the CPs, none appear overly useful to me |
| 14:29 | Stevef_ | "I guess I will let other people debate it" yes |
| 15:08 | <jgraham> | Huh, what does gecko do for location.reload(argument) ? |
| 15:09 | <jgraham> | For reasons I don't entirely understand, Opera has location.reload(bool force) |
| 15:09 | <jgraham> | With force = true meaning "don't reload from cache" |
| 15:09 | <jgraham> | But gecko seems to have almost the opposite behaviour |
| 15:10 | <zewt> | iirc webkit location.reload() with no argument forces a reload |
| 15:10 | <zewt> | hit that yesterday, had to change a bunch of location.reload to location.href = location.href to make sure it's just a refresh |
| 15:11 | <jgraham> | zewt: Per the TC I am looking at it seems that gecko and webkit have different behaviours for an iframe compared to a top level browsing context |
| 15:11 | <jgraham> | For an iframe webkit always force-reloads |
| 15:12 | <jgraham> | Gecko also, I think |
| 15:12 | <jgraham> | For a tlbc WebKit never force reloads, Gecko only does if you pass in false |
| 15:12 | <zewt> | this was just a top-level window |
| 15:12 | <jgraham> | Hmm |
| 15:13 | <zewt> | i can recheck, i saw it reloading images though |
| 15:13 | smaug____ | looks at location implementation |
| 15:14 | <smaug____> | btw, assign() has been implemented in different ways in different browsers |
| 15:15 | <smaug____> | reload(true) sets the flags to bypass cache |
| 15:15 | <jgraham> | smaug____: The "if the session history contains only one document and that's the about:blank document" bit, or something else? |
| 15:15 | <smaug____> | those flags don't have anything to do with session history |
| 15:16 | <jgraham> | smaug____: I meant for "assign" |
| 15:17 | <smaug____> | oh |
| 15:17 | <jgraham> | smaug____: I swear that this TC shows gecko having exactly the opposite behaviour for reload :) |
| 15:18 | <smaug____> | https://bugzilla.mozilla.org/show_bug.cgi?id=754029#c50 |
| 15:20 | <jgraham> | I don't really understand that comment |
| 15:20 | <jgraham> | Maybe I will if I read the other 49 |
| 15:20 | <jgraham> | Everything about history makes me cry |
| 15:21 | <jgraham> | Who knew that the fundamental navigation metaphor of the web was so incompatible across implementations |
| 15:22 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18542 soooo i guess firefox should rename wheel to mousewheel and d3e has to suck it up |
| 15:22 | <jgraham> | smaug____: If you break the spec here, you will file a bug and CC me, right? |
| 15:23 | <zcorpan> | $ grep -aPic "\sonwheel\s*=" web200904 |
| 15:23 | <zcorpan> | 0 |
| 15:24 | <smaug____> | jgraham: break the spec where :) all session history handling is underspec'ed |
| 15:25 | <smaug____> | jgraham: obviously you want to write a spec for it... can't wait to see it ;) |
| 15:27 | <jgraham> | smaug____: Hixie wants to write a spec for it :p |
| 15:27 | <jgraham> | Indeed that's what he gets paid the big bucks to do |
| 15:27 | jgraham | finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=17041 |
| 15:29 | <jgraham> | smaug____: But it isn't much help to anyone if no one is even reporting bugs on the issues |
| 15:29 | <jgraham> | (although bz did in this case) |
| 15:29 | <jgraham> | Because then the spec will just continue being wrong |
| 15:30 | <jgraham> | (and implementations will continue being incompatible) |
| 15:32 | <jgraham> | (ideally people would also submit testcases, although I understand why that can be difficult) |
| 15:33 | <smaug____> | it has been a bit hard to file bugs, when the spec seems to miss so many things |
| 15:34 | <jgraham> | It has been a bit hard to make our implementation match others when they didn't bother to file bugs :) |
| 15:34 | <smaug____> | yup |
| 15:34 | smaug____ | has tried to follow IE |
| 15:34 | jgraham | has tried to file bugs |
| 15:35 | <jgraham> | And I think I have largely succeeded |
| 15:35 | <smaug____> | since it has traditionally have the least badly behaving sh implementation |
| 15:35 | <jgraham> | That is, every time we have found that we have to deviate from the spec, I have tried to file a bug |
| 15:35 | <jgraham> | I probably missed some, but it hasn't been impossible |
| 15:38 | <Hixie> | zcorpan: that license doesn't allow commercial re-use, as far as i can tell. plus, hey, it's not that ugly :-P |
| 15:38 | <Hixie> | smaug____: it's not _that_ underdefined any more is it? :-) |
| 15:39 | <Hixie> | hsivonen: note that the CPs in question apply to a part of the spec that has long since forked in the WHATWG space |
| 15:39 | <zcorpan> | Hixie: dang. well, i still stand by that it's ugly :-P |
| 15:41 | <Hixie> | :-P |
| 15:41 | <zcorpan> | Hixie: scan your own finger print and use that :-) |
| 15:41 | <Hixie> | technically iirc the picture was a picture of my own fingerprint, drawn in Markers on android :-) |
| 15:42 | <Hixie> | unfortunately with the size of my screen and the size of my finger it's like trying to draw with a felt tip pen on a postage stamp |
| 15:42 | <Hixie> | i really need a tablet or something |
| 15:46 | <jgraham> | Just ask the original author to relicense it |
| 16:01 | <dglazkov> | good morning, Whatwg! |
| 16:02 | <Ms2ger> | G'day |
| 17:02 | <zewt> | man, ontransitionend is a nightmare |
| 17:02 | <Ms2ger> | <link rel=intent> |
| 17:02 | <Ms2ger> | Hixie is going to be so happy |
| 17:03 | <zewt> | need to jump all kinds of hoops to figure out whether a particular style change will trigger it, and if you get it wrong you miss the event and likely fall apart |
| 17:06 | <tantek> | Ms2ger - why are intents special? We already have a way to link to application manifests, which include, among other things, what "activities" an app will handle. |
| 17:06 | <tantek> | no need for separate links to intents |
| 17:06 | <tantek> | app manifests already cover this |
| 17:06 | <hober> | also, why are we propagating the crazy word "intent" for this? |
| 17:06 | <tantek> | this smells of the "my feature is so important it deserves it's own element" reasoning |
| 17:06 | <tantek> | yeah |
| 17:07 | <hober> | "capability" or "action" would at least *make sense* |
| 17:07 | <miketaylr> | +1 |
| 17:12 | <tantek> | hober - yeah, hence "web actions" |
| 17:13 | <hsivonen> | Ms2ger: Hixie's happiness comes last in the priority of constituents |
| 17:14 | <Ms2ger> | hsivonen, I would put a few other persons' happiness a little later still ;) |
| 17:14 | <tantek> | per "my feature is so important…" design: http://w3cmemes.tumblr.com/post/22399681762 |
| 17:15 | <tantek> | the lesser version of that is, "my feature/company is so important, it needs its own rel value" |
| 17:16 | <tantek> | btw, the aforementioned app manifest spec: http://mozilla.github.com/webapps-spec/ |
| 17:16 | <tantek> | Hober - I would welcome a "capability" addition to that spec |
| 17:16 | <tantek> | so we don't have invent yet another special case code path for something like "intents" |
| 17:17 | <tantek> | that's where this kind of thing (intents/activities) belongs |
| 17:17 | <tantek> | in the app manifest that describes all sorts of things about what the app does / needs. |
| 17:17 | <hsivonen> | I wonder who chose wolves at http://25.media.tumblr.com/tumblr_m8iuvfm9o81rvsbh9o1_500.jpg and http://24.media.tumblr.com/tumblr_m8iuliq6Ns1rvsbh9o2_500.jpg ... |
| 17:18 | <Ms2ger> | hsivonen, I believe Insanity Wolf did |
| 17:18 | <tantek> | hober, here's the current "capability" style declaration that we're adding to the app manifest in a declarative way that serves the same purpose as Google's intents: https://wiki.mozilla.org/WebAPI/WebActivities#Declarative_registration |
| 17:19 | <tantek> | add that to the aforementioned app manifest and you're good to go |
| 17:19 | <tantek> | no need for new elements, nor rel values |
| 17:19 | <Ms2ger> | Everything solved |
| 17:19 | <Ms2ger> | Let's go shopping |
| 17:20 | <tantek> | Ms2ger - they will be once we ship that support in FirefoxOS on devices. |
| 17:21 | <tantek> | But you'll have to go to Brazil to shop for those (for now) |
| 17:22 | <Ms2ger> | I sure am glad that the b2g team can solve every single problem in this industry on their own. |
| 17:23 | <tantek> | Ms2ger - no, just the ones that DAP/W3C have failed to solve. |
| 17:24 | <tantek> | And you know the drill, patches welcome ;) |
| 17:24 | Ms2ger | can't remember any problem DAP solved |
| 17:24 | <tantek> | you're welcome to /join #webapi on irc.mozilla.org |
| 17:24 | jgraham | finds the idea of general purpose manifests more scary than intents |
| 17:24 | <Hixie> | hsivonen: nah, theoretical purity comes even after that :-) |
| 17:24 | <tantek> | and speak your critically rational mind :) |
| 17:24 | <hsivonen> | Hixie: can it be happy? |
| 17:24 | <Ms2ger> | tantek, thanks for proving the point :) |
| 17:25 | <jgraham> | tantek: The right solution to "W3C failed to solve this problem" is not "let's invent a proprietry solution" |
| 17:25 | <Hixie> | hsivonen: the people who care about it can be :-) |
| 17:25 | <tantek> | jgraham - nothing proprietary about it |
| 17:25 | <hsivonen> | Hixie: fair enough |
| 17:25 | <tantek> | it's a counterproposal to W3C/DAP drafts that failed (or are failing) |
| 17:25 | <hsivonen> | tantek: well, there's a whole lot of "moz" prefixing in WebAPI |
| 17:25 | <jgraham> | tantek: Which open forum is being used to develop the spec? |
| 17:26 | <tantek> | hsivonen - I'm not a fan of moz prefixing in WebAPI - I've been changing my mind on that |
| 17:26 | <jgraham> | A mozilla-specific IRC channel doesn't count |
| 17:26 | <tantek> | why? it's open |
| 17:26 | <tantek> | or you just hating on the string "mozilla" ? |
| 17:27 | Ms2ger | yawns |
| 17:27 | <smaug____> | ;) |
| 17:27 | <Ms2ger> | This has been discussed often enough |
| 17:27 | <jgraham> | It clearly signals ownership |
| 17:27 | <jgraham> | You should do it at WHATWG if you are serious about it being non-proprietary |
| 17:27 | <tantek> | unlike a spec that only has editors from a single company? |
| 17:28 | <tantek> | WHATWG has no monopoly on non-proprietariness |
| 17:28 | <jgraham> | If *that* was a criterion then pretty much every non-CSS spec would be proprietary |
| 17:28 | <tantek> | nah - just the specs with heaps of Google editors |
| 17:28 | <Ms2ger> | What makes you think we like those? |
| 17:28 | <jgraham> | And CSS would only get by because no one actually ever finishes the damn specs |
| 17:28 | <tantek> | (and no other companies represented) |
| 17:29 | <tantek> | jgraham - I though |
| 17:29 | <Hixie> | (what makes you think even _google_ likes those?) |
| 17:29 | <jgraham> | Sure, there are things that Google are doing that should be more open |
| 17:29 | <tantek> | thought* "no[t] finish[ing] damn specs" was preferred here at WHATWG ;) |
| 17:29 | <jgraham> | That doesn't give Moz. a free pass to be just as bad |
| 17:29 | <tantek> | AKA "living specs" |
| 17:29 | <jgraham> | tantek: The CSS specs I have in mind spent years as more dead than alive |
| 17:30 | <tantek> | jgraham, sorry I couldn't read your mind for particular strawmen. |
| 17:30 | <Ms2ger> | Are you going off on a tangent because you agree that those WebAPI specs are proprietary? |
| 17:30 | <jgraham> | (in fact Mozilla holds itself to a higher standard, so you shouldn't be surprised when other people also hold you to a higher standard) |
| 17:30 | <tantek> | if you have any particular favorite CSS specs you'd like to see resuscitated, let me and hober and tabatkins know - we're sitting in the CSSWG f2f now |
| 17:31 | <tantek> | jgraham - absolutely - keep it up |
| 17:31 | <Ms2ger> | CSS3-UI |
| 17:31 | <hober> | hahahahahahaa |
| 17:31 | hsivonen | would prefer Google's SPDY over an "open" HTTP/2.0 that has had people in the intercept business water it down |
| 17:31 | <jgraham> | My point is that CSS is pretty much the only group that regularly has multiple editors from multiple compaies per spec |
| 17:31 | <tantek> | Ms2ger - what edits do you need/want in CSS3-UI |
| 17:31 | <tantek> | ? |
| 17:31 | <Hixie> | specs shouldn't have multiple editors, it just leads to shared credit and diluted blame |
| 17:32 | <Ms2ger> | tantek, implementations |
| 17:32 | <Hixie> | specs should have a single editor who is given full responsibility and who is clearly entirely to blame when mistakes are made |
| 17:32 | <tantek> | Hixie - my experience has been to the contrary many times |
| 17:32 | <Hixie> | that's the way you ensure quality |
| 17:32 | <Ms2ger> | Oh, and tests |
| 17:32 | <smaug____> | jgraham: WebApps how often multiple editors, and at least feedback from multiple companies |
| 17:32 | <smaug____> | s/how/has/ |
| 17:32 | <tantek> | The most recent CSS3-UI last call closed, and I'm looking at *dropping* features that didn't get implemented |
| 17:32 | <jgraham> | I don't care who *writes* the specs |
| 17:32 | <tantek> | like all the nav-* stuff |
| 17:33 | <tantek> | Ms2ger - most of CSS3-UI is implementee |
| 17:33 | <jgraham> | Except insofar as some people are better at it than others |
| 17:33 | <tantek> | implemented* even |
| 17:33 | <tantek> | which features in particular are you missing? |
| 17:33 | <tantek> | and yes, tests needed. contributions welcome. |
| 17:33 | <tantek> | (which is true for nearly all specs) |
| 17:34 | <jgraham> | I care about the specs having a development process that encourages feedback from multiple sources and is likely to lead to multiple interoperable implementations |
| 17:34 | <tantek> | jgraham - of course |
| 17:34 | <hsivonen> | (I still don't see the upside of letting the IETF get its hands on SPDY. https://plus.google.com/100166083286297802191/posts/hoYbGxrSuWm ) |
| 17:34 | <jgraham> | However you cut it "Mozilla IRC channels" are not a venue that encourages feedback from multiple vendors |
| 17:34 | <hober> | jgraham: weird. :) |
| 17:35 | <tantek> | hsivonen - what is the upside of letting IETF get its hands on anything? |
| 17:35 | <tantek> | jgraham - plenty of non-mozilla people in mozilla IRC channels |
| 17:35 | <Hixie> | (examples: CSS2.1, SVG, HTML4, DOM3 Events, Selectors, backgrounds&borders -- all specs where nobody has taken full responsibility for the problems, but lots of people have claimed credit for the successes) |
| 17:35 | <Ms2ger> | Hixie, DOM4? :) |
| 17:35 | <Hixie> | (i'm one of those with 2.1, e.g.) |
| 17:35 | <hsivonen> | tantek: in theory, getting adoption and interop, but SPDY seems doing fine on those points without the IETF |
| 17:35 | <jgraham> | tantek: So what? |
| 17:35 | <Hixie> | Ms2ger: that one hasn't had problems to take responsibility for, so far :-) |
| 17:35 | <tantek> | Hixie, I think we've both shared plenty of blame on 2.1 |
| 17:35 | <Hixie> | tantek: exactly |
| 17:35 | <jgraham> | tantek: Why won't you bring those specs to whatwg? |
| 17:36 | <Hixie> | tantek: yet neither of us has done anything about it |
| 17:36 | <tantek> | jgraham, me personally? email-centric culture sucks. others? you're welcome to ask the editors. |
| 17:36 | <Ms2ger> | Email is a support forim |
| 17:36 | <Ms2ger> | Just so we got that behind us |
| 17:36 | <tantek> | thank you Ms2ger ;) |
| 17:36 | <Hixie> | spec development and discussion should happen on twitter! |
| 17:37 | <tantek> | Hixie - I'm back at the CSSWG f2f meetings and such trying to help improve the CSS specs. As are the rest of the people in the room. |
| 17:37 | <Hixie> | tantek: meetings don't improve specs |
| 17:37 | <Ms2ger> | F2F meetings are a support forum? |
| 17:37 | <odinho_> | Yes |
| 17:38 | <tantek> | Hixie, I've seen smaller meetings, e.g. between Tab and fantasai - drastically improve specs |
| 17:38 | <tantek> | there are plenty of counter-examples to your general assertion |
| 17:38 | <tantek> | meetings can easily be completely unproductive - but doesn't mean they always are. |
| 17:38 | <Ms2ger> | The claim was clearly about WG meetings |
| 17:38 | <tantek> | anyway - it's one way of "doing something about it" |
| 17:39 | <Ms2ger> | Not sure why you're trying a strawman again |
| 17:39 | <tantek> | Ms2ger - which W G meeting(s) have you participated in ? |
| 17:39 | <tantek> | or are you merely armchair commenting about them? |
| 17:39 | <Ms2ger> | I'm not commenting about them, Hixie is |
| 17:40 | <odinho> | tantek: You don't need to participate in person to see how they work. And what output it has on the spec afterwards. |
| 17:40 | <Hixie> | he was correctly interpreting my statement |
| 17:40 | <Ms2ger> | Are you deliberately misunderstanding? |
| 17:40 | <Ms2ger> | * fantasai is totally ignoring this entire discussion because we've had the exact same discussion with the exact same points at every single one of the past F2Fs since Exclusions was proposed. |
| 17:40 | <tantek> | odinho - hence "armchair" |
| 17:40 | <Ms2ger> | I guess that's a relevant point from a F2F participant |
| 17:41 | <tantek> | grids/exclusions tend to be very contentious yeah, unfortunately |
| 17:44 | <jgraham> | tantek: I am convinced that WHATWG participants would be flexible about how they gave feedback on specs if they felt that the spec was sufficiently valuable |
| 17:45 | <Hixie> | yeah there's nothing about the whatwg that says spec editors have to use the mailing list for feedback |
| 17:45 | <Hixie> | i'm happy to help people set up whatever mechanisms people want |
| 17:45 | <Hixie> | and the w3c has in the past helped too |
| 17:45 | <Hixie> | e.g. we use their bugzilla |
| 17:45 | <Hixie> | we have a web forum, a blog, a wiki |
| 17:45 | <Hixie> | all of which are available to any editors (or anyone else) who needs and wants to use them |
| 17:46 | <Hixie> | also this IRC channel, and anyone can of course set up new ones |
| 17:46 | <tantek> | Hixie, not everyone seems to agree with your sentiment that "anyone can of course set up new ones" |
| 17:46 | <Hixie> | the twitter account's password is available to anyone who wants to use it, should spec-feedback-by-twitter be a serious desire |
| 17:46 | <tantek> | which is essentially exactly what's happened with WebAPIs |
| 17:46 | <Hixie> | tantek: it's literally as easy as typing /join #foo |
| 17:47 | <jgraham> | tantek: I see no evidence that WebAPIs are being edited in any sort of vendor-neutral space. It appears to be a Mozilla-internal thing that just happens to be public because lots of Mozilla things are in public |
| 17:48 | <tantek> | jgraham - I'd like to see the specs edited in a more vendor neutral space as well. That being said, public input is certainly being encouraged an incorporated. |
| 17:49 | <hsivonen> | tantek: Regarding the Mozilla-specific also Web API, I think design decisions such as the one involved in https://bugzilla.mozilla.org/show_bug.cgi?id=774621 (IIRC, the only Web API design decision for which my input has been specifically solicited) could benefit from multi-vendor exposure. |
| 17:49 | <tantek> | hsivonen - *in general* design decisions on WebAPIs could benefit from multi-vendor exposure. |
| 17:49 | <hsivonen> | s/specific also/specificness/ |
| 17:49 | <Hixie> | lordy, an sms api |
| 17:49 | <Hixie> | i remember speccing one of those back at opera |
| 17:50 | <hober> | Hixie: bleah |
| 17:50 | <Hixie> | good to know that doing that is still in fashion |
| 17:50 | <tantek> | Hixie - the full list is here: https://wiki.mozilla.org/WebAPI/ |
| 17:50 | <tantek> | Hixie, yeah, people seems to use SMS a lot. Who knew? |
| 17:50 | <Hixie> | tantek: i've seen it (tried to adopt some of them for the web intents proposal i made) |
| 17:50 | <hsivonen> | Hixie: Opera FIRST! |
| 17:50 | <Hixie> | hsivonen: oh we weren't first |
| 17:50 | <Hixie> | hsivonen: my own api for this was informed by prior art |
| 17:50 | <tantek> | if email lists are your thing, there's also https://lists.mozilla.org/listinfo/dev-webapi |
| 17:52 | <Hixie> | tantek: btw, in general in my experence when a vendor A tells another vendor B that they feel that work is being done by B in a vendor-specific way, it doesn't matter if A is right or wrong; the technology will fail as a multi-vendor standard unless changes are made to make A feel like it's vendor-neutral. |
| 17:52 | <Hixie> | tantek: (not commenting in particular on the mozilla thing here, nor on whether google is any good at this either) |
| 17:53 | <tantek> | Hixie, indeed that's a common pattern |
| 17:53 | <tantek> | and a risk |
| 17:54 | <hsivonen> | Hixie: does Opera Mobile ship the API you designed? |
| 17:55 | <Hixie> | hsivonen: no idea, i spent as little time as possible on that proprietary api as i could |
| 17:55 | <jgraham> | (not as far as I know) |
| 17:55 | <Hixie> | (opera requiring me to spend any time on proprietary stuff at all was one of the reasons i looked for alternate employment) |
| 17:56 | <jgraham> | (but I don't know much about non-Web APIs) |
| 17:56 | <hsivonen> | What happened to Opera Platform from 2006 or so? |
| 17:59 | jgraham | wonders who might know that kind of thing |
| 18:05 | <Ms2ger> | hsivonen, oh, dunno if you saw the sniffing issues people had with Mozilla's ZIP API, I thought you might be interested |
| 18:06 | <hsivonen> | Ms2ger: I did |
| 18:08 | <hsivonen> | Ms2ger: I saw https://bugzilla.mozilla.org/show_bug.cgi?id=781425 |
| 18:09 | <Ms2ger> | That's the one I was thinking of, according to firebot |
| 21:09 | <zewt> | opera doesn't do pointer-events? seriously? |
| 21:14 | <smaug____> | svg pointer-events I guess |
| 21:14 | <smaug____> | not MS Pointer Events |
| 21:14 | <miketaylr> | opera has svg pointer-events, not the CSS ones currently |
| 21:22 | <tantek> | zewt - what's your use case for pointer-events? which value(s) in particular in what situation? (honest question as I'm likely to be the one speccing it in css4-ui) |
| 21:24 | <zewt> | i'm using it to make sure things that use CSS opacity:0 transitions aren't clickable when they're hidden, to disable clicks on elements that are transitioning on/off screens, to prevent transparent elements that overlap clickable ones from getting in the way, etc |
| 21:24 | <zewt> | they're all things that can be worked around with varying levels of effort, but just setting pointer-events: none is so much quicker |
| 21:37 | <Wilto> | ♡ pointer-events: none; |
| 21:37 | <Wilto> | Just sayin’. |
| 21:59 | <zewt> | nice to see a bit of support from MS on autoRevoke, since they seemed to be digging in their heels before |
| 22:02 | <tantek> | zewt, wilto, thanks - appreciated. |
| 22:03 | <tantek> | zewt, the specifics you provided are particularly helpful. |
| 22:09 | <tantek> | captured: http://wiki.csswg.org/spec/css4-ui#pointer-events |
| 22:20 | <zewt> | bleh, why is <label for> an ID; probably means I can't use them at all and need to implement it myself |
| 22:20 | <zewt> | (since I'm wholesale cloning multiple copies of something containing a <form>) |
| 22:37 | <zewt> | can't do dataset["a-b"] = "c"? :| |
| 22:38 | <zewt> | oh god, it doesn't *seriously* convert camel case |
| 22:39 | <zewt> | that's horrifying |
| 22:42 | <zewt> | i was concerned about it stripping data- (because it means I have to remember to strip "data-" when grepping for where [data-foo] is modified), but this is just obfuscation |
| 22:56 | <Hixie> | zewt: don't use the [] stuff, just use direct indexing, as in dataset.aB |
| 23:02 | <zewt> | that's no better, it still obfuscates my identifiers |
| 23:03 | <Hixie> | "obfuscates"? |
| 23:03 | <Hixie> | i'm not sure i understand what you're complaining about |
| 23:04 | <zewt> | if I have "[data-foo-bar=bar]" in CSS, i don't want to have to play games trying to figure out that I need to grep for "fooBar" to figure out where it's coming from |
| 23:05 | <tantek> | zewt - the alternative to <label for> is to use <label> to wrap the element it applies to e.g. <label><input/></label> - would that work in your case? |
| 23:08 | <zewt> | may take some style changes to make it work |
| 23:08 | <Hixie> | zewt: so use setAttribute |
| 23:08 | <Hixie> | zewt: (there's no need to play games, it's the same logic as is used for other IDL attributes) |
