| 01:14 | <montecfel> | Hmm. |
| 01:14 | <montecfel> | It is not possible to invoke fullscreen unless the user clicks? |
| 01:14 | <montecfel> | I tried to make Alt + Enter go into fullscreen, but it doesn't work. It only works when there is a click event. |
| 01:16 | <montecfel> | You can probably ignore that. |
| 01:23 | <montecfel> | "Request for full-screen was denied because Element.mozRequestFullScreen() was not called from inside a short running user-generated event handler." |
| 01:23 | <montecfel> | Huh? :/ |
| 01:28 | <caitp> | it doesn't look like there's anything normative about disallowing that outside of event handlers, montecfel |
| 01:28 | <montecfel> | Well... hrm. |
| 01:28 | <montecfel> | How do I detect if a modifier key was pressed together with the e.keyCode? |
| 01:28 | <caitp> | more craziness from moco? why not! |
| 01:28 | <montecfel> | caitp: ? |
| 01:28 | <caitp> | oh, I know the answer to that, hang on |
| 01:29 | <montecfel> | moco = Mozilla Corporation? |
| 01:29 | <montecfel> | Yes, they sure are being very do-everything-except-for-working-on-the-actual-browser-y lately. |
| 01:29 | <caitp> | the keyboardevent interface has some properties for modifier keys, like altKey |
| 01:29 | <montecfel> | Lately = last 5-10 years? |
| 01:29 | <montecfel> | Yeah... |
| 01:29 | <montecfel> | Is Ctrl + Enter or Alt + Enter the classic "go to fullscreen" or "go out from fullscreen" key combo? |
| 01:30 | <montecfel> | Alt + Enter, I believe. |
| 01:30 | <montecfel> | Do you mean it's e.altKey? |
| 01:30 | <caitp> | yeah |
| 01:31 | <montecfel> | And it's just a boolean? |
| 01:31 | <caitp> | I think that's from DOM 2 or something |
| 01:31 | <montecfel> | Finally something that makes sense! |
| 01:32 | <MikeSmith> | TabAtkins_: you'll probably be unhappy to know that when I land @sizes checking support in the validator, it's going to accept pretty much anything within calc(...), because the kludgey way I handle it for now only just looks for "calc" followed by balanced parens |
| 01:32 | <caitp> | guess i'm wrong, dom3 |
| 01:33 | <MikeSmith> | TabAtkins_: for the validator I really can't justify the time needed to stop and write a full CSS tokenizer to handle this one single attribute in the entire language that would benefit from it, as far as conformance checking goes |
| 01:34 | <MikeSmith> | @sizes is seeming more and more to me like a layering violation |
| 01:35 | <MikeSmith> | not that I'm a purist. I guess it's probably a justified violation in this case. But still it's punching holes. |
| 01:44 | <MikeSmith> | Hixie: Domenic I wouldn't call the brand-color thing a kerfuffle either. I'd call it a wilful abuse of the spirit of requirements. The arrogance displayed in that thread is worthy of bad-old-days Microsoft or whatever other "evil" incarnantion of some org just flipping the bird to everybody else |
| 01:45 | <MikeSmith> | I suspect we probably have more instances of that kind of stuff to look forward to |
| 01:47 | <a-ja> | MikeSmith: haven't read followups to that discussion in a few days....new developments? |
| 01:47 | <MikeSmith> | the rationalization around it that followed was even more disappointing than the initial act of abusing the implicit contract |
| 01:47 | <Hixie> | the worst imho is that this was the third instance of this |
| 01:47 | <Hixie> | for this very feature |
| 01:47 | <MikeSmith> | a-ja: no I've not read any followups to it during the last week or so.. Not sure if there have been any |
| 01:48 | <Hixie> | so three vendors had the same arrogance and missing-the-point-ness |
| 01:48 | <MikeSmith> | Hixie: well, that too |
| 01:48 | <MikeSmith> | that exactly |
| 01:48 | <a-ja> | MikeSmith: agree with your "evil" categorization, fwiw |
| 01:48 | <Hixie> | which i kinda take as an indication of failure on the part of standards advocacy :-( |
| 01:49 | <MikeSmith> | Hixie: well, we sort of expect that everybody will be a good actor |
| 01:50 | <SamB> | I'm missing the context :-( |
| 01:51 | <MikeSmith> | a-ja: evil is what organizations other than yours do |
| 01:51 | <a-ja> | heh |
| 01:52 | <MikeSmith> | SamB: thread on blink-dev about an intent-to-ship for meta@name=brand-colorg |
| 01:52 | <MikeSmith> | *color |
| 01:54 | <SamB> | Hixie: so this is the THIRD time somebody has done ... what exactly? |
| 01:55 | <Hixie> | SamB: invented a proprietary value to colour system ui for the page |
| 01:55 | <SamB> | Hixie: ah |
| 01:55 | <SamB> | Hixie: so like IE's scrollbar thing? |
| 01:55 | <Hixie> | yeah |
| 01:55 | <Hixie> | specifically, doing so without getting other vendors to buy in |
| 01:56 | <SamB> | what was the other one? |
| 01:56 | <MikeSmith> | Hixie: anyway I agree with Domenic's proposal about "if your meta tag changes user agent behavior, it needs to be in this spec" or some such language |
| 01:57 | Hixie | shrugs |
| 01:57 | <Hixie> | i don't think it would make that much difference |
| 01:58 | <Hixie> | but in any case |
| 01:58 | <MikeSmith> | Hixie: also btw and fwiw even if we had implemented your proposal for validator refinements for meta@name, I don't think it would have prevented this case -- or this set of three cases |
| 01:58 | <Hixie> | i want to change that whole extension model |
| 01:58 | <Hixie> | and i'm just waiting for hsivonen's feedback |
| 01:58 | <Hixie> | yeah, that's good feedback on the proposal |
| 01:59 | <MikeSmith> | Hixie: feedback to which proposal? Your message at the beginning of the year wasn't a proposal for changing the whole extension model, was it? |
| 01:59 | <MikeSmith> | Hixie: I mean what feedback are you waiting on from Henri |
| 01:59 | <caitp> | don't worry dude, in the future web compat won't matter because we'll be making people write 12 versions of their applications for hundreds of different smartphones, tablets, gps machines, laundrey machines, etc, and nobody will even remember a time when the same document looked more or less the same on a different device |
| 02:00 | <SamB> | caitp: you have a funny way of beginning that sentence |
| 02:01 | <caitp> | you have to read it with just the right tone to really get it |
| 02:03 | <SamB> | oh, now I see |
| 02:04 | <MikeSmith> | caitp: on the plus side, I guess we can look forward to people's sigs saying "Sent from my laundry machine." |
| 02:04 | <SamB> | the other two times are listed RIGHT IN THE FIRST DAMN POST and they can't see this is a bad idea? |
| 02:05 | <Hixie> | MikeSmith: it was a start to a proposal, but yeah, not a complete one. |
| 02:05 | <Hixie> | MikeSmith: that's what i'd like to see hsivonen's feedback on, though |
| 02:06 | <SamB> | From: "'Alex Russell' via blink-dev" <blink-dev⊙co> |
| 02:06 | SamB | wonders wth the "via blink-dev" bit is for |
| 02:07 | <MikeSmith> | SamB: I think http://goo.gl/mxQwE pretty well captures their attitude toward what other people think about it being a bad idea |
| 02:08 | <MikeSmith> | SamB: I think that just indicates the message was sent from the Web interface |
| 02:08 | <MikeSmith> | SamB: rather than by e-mail |
| 02:08 | <SamB> | why are they poluting my gnus view with such inane distractions |
| 02:09 | MikeSmith | adds SamB to the list of crazy people like hober and Haakon that use emacs for reading mail |
| 02:10 | <SamB> | MikeSmith: well, the first post looked terrible on gmane classic, so I foolishly hoped it would look better in gnus |
| 02:10 | <SamB> | anyway, it's not mail, it's news, obviously |
| 02:10 | <MikeSmith> | nothing is obvious to me when it comes to emacs |
| 02:13 | <MikeSmith> | Hixie: also btw and fwiw at this point, I recently did at least update the validator to quit having the list of meta@name and a|link@rel values hardcoded. They are now pulled in a build time from http://help.whatwg.org/extensions/meta-name/ and http://help.whatwg.org/extensions/a-rel/ and http://help.whatwg.org/extensions/link-rel/ |
| 02:13 | <MikeSmith> | Hixie: which are just generated by python scripts that scrape the wiki |
| 02:14 | <MikeSmith> | Hixie: so they're not updated real time but at least it's progress over what we were doing before |
| 02:14 | <Hixie> | MikeSmith: cool |
| 02:16 | <roc> | montecfel: FWIW, as one of the gazillions of people Mozilla people working on the browser, I somewhat resent the suggestion that we aren't. |
| 02:24 | <montecfel> | roc: What about all the weird projects that Mozilla are announcing all the time? Why is the browser and all the issues that still exist never heard of, basically? |
| 02:25 | <montecfel> | This latest IDE-in-the-browser is very "inner system"-y. |
| 02:41 | <roc> | What you hear about is not entirely under our control |
| 02:41 | <roc> | if you look at https://hacks.mozilla.org/, you will see a lot of articles there about devtools and new browser engine features |
| 02:42 | <roc> | if you're more interested in the front end, there was a major UI change that shipped recently that you may have heard about |
| 02:43 | <caitp> | they are working on the browser, and lots of other stuff too, credit where credits due |
| 03:08 | <MikeSmith> | yeah as far as any perceived never-heard-of problem, I can't see that there's any shortage of information going out about new gecko browser-engine features |
| 03:09 | <MikeSmith> | https://hacks.mozilla.org/ and the related twitter account are a great source of info |
| 03:12 | <MikeSmith> | and as far as announcements about the IDE-in-the-browser thing, that doesn't seem to me at all like a weird project at all. Clearly it's something intended to meet needs of the same web devs that care about the core browser-engine features |
| 03:18 | <SamB> | I'd suggest a SWANK backend, if SLIME would ever get its ass in gear and at least pretend to have a stable protocol ... |
| 03:21 | <MikeSmith> | SamB: SLIME and SWANK are real things, or some kind of troll you're trying to catch me with |
| 03:21 | <MikeSmith> | SamB: ah, emacs |
| 03:22 | <SamB> | yeah, emacs |
| 03:22 | <MikeSmith> | you got me |
| 03:22 | <SamB> | real things |
| 03:22 | <MikeSmith> | I feel for it |
| 03:22 | <MikeSmith> | nice troll |
| 03:22 | <MikeSmith> | emacs-rolled me |
| 03:23 | <SamB> | Slime is a CL IDE for Emacs that's better than the builtin support for Emacs Lisp. And it's been abused to work with lots of things that aren't CL, too ... |
| 03:24 | <MikeSmith> | ah OK |
| 03:25 | <MikeSmith> | that's novel, emacs being abused to do things that are better handled with other things |
| 03:29 | <jory> | Mmmmm, emacs... delicious. |
| 03:34 | <SamB> | I'm not actually aware of a more fertile ground for mail/news implementations than Emacs; are you? |
| 03:35 | <SamB> | nevermind that it comes with not one but TWO irc clients ;-P |
| 03:35 | <jory> | Of course, "It's all just text" |
| 05:23 | <caitp> | having fun with the promise implementation? :p |
| 05:27 | <Domenic> | caitp: awesome response time |
| 11:21 | <smaug____> | Hixie: curious, why http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-media says "should". Any reason to not "must"? (Someone was just about to change image document content in Gecko and said that isn't against of the spec because of that "should") |
| 11:21 | smaug____ | r-'ed that patch |
| 11:28 | <Ms2ger> | smaug____, well, then they don't know what "SHOULD" means :) |
| 12:38 | <SimonSapin> | must (but we know you won’t) |
| 14:03 | <mounir> | Domenic: ping |
| 14:04 | <Domenic> | mounir: pong |
| 14:04 | <mounir> | Domenic: regarding https://github.com/w3c/screen-orientation/issues/13 |
| 14:05 | <mounir> | Domenic: I'm not sure how we can avoid screen.orientation != screen.orientation (comment 4) |
| 14:05 | <mounir> | Domenic: unless we do very complicated things |
| 14:05 | <mounir> | Domenic: is it something you care about? |
| 14:05 | <Domenic> | mounir: yes, it is something I care about very much |
| 14:06 | <Domenic> | mounir: I am happy to write up the spec text if necessary. We need to set an example on how to do this for other specs, since WebIDL is deficient. |
| 14:06 | <mounir> | Domenic: screen.orientation would be an Object if I understand correctly, right? |
| 14:07 | <mounir> | Domenic: but in order to have equality, we would need to return exactly the same object |
| 14:07 | <Domenic> | mounir: yep. Just think of how you would implement this in JavaScript. |
| 14:08 | <mounir> | Domenic: so, doing that for screen.orientation isn't much of a pain |
| 14:09 | <mounir> | Domenic: making screen.lockOrientation() promise being fulfiled with an object that is equal to screen.orientation when they are the same is... more of a pain |
| 14:09 | <Ms2ger> | Domenic, no |
| 14:09 | <Domenic> | mounir: I don't care about that as much, but it also seems pretty easy |
| 14:09 | <Ms2ger> | Domenic, if IDL is deficient, fix IDL |
| 14:09 | <mounir> | Ms2ger: might take years :) |
| 14:09 | <Domenic> | mounir: just say "resolve p with the value of this.orientation" |
| 14:10 | <Domenic> | Ms2ger: fair. I have time for that now. |
| 14:10 | <mounir> | Domenic: this.orientation is updated after the promise is resolved ;) |
| 14:10 | <Domenic> | mounir: why? |
| 14:10 | <Ms2ger> | Thanks |
| 14:11 | <mounir> | Domenic: to prevent orientationchange event handlers to fire before |
| 14:11 | <Domenic> | mounir: what is the exact sequence? orientationchange fires, promise resolves, value changes? |
| 14:11 | <mounir> | no |
| 14:12 | <mounir> | promise resolved |
| 14:12 | <mounir> | value changes |
| 14:12 | <Domenic> | It seems wierd that lockOrientation().then(() => screen.orientation is wrong) |
| 14:12 | <mounir> | event fires |
| 14:12 | <Domenic> | ok. why not make it value changes, promise resolved, event fires |
| 14:15 | <annevk> | and from the same task, pretty please |
| 14:15 | <mounir> | yeah, I guess we could do that |
| 14:15 | <annevk> | (promise will learn about it after the event that way, but that seems fine) |
| 14:15 | <mounir> | that's going to be a pain to implement... |
| 14:16 | <annevk> | mounir: why? |
| 14:16 | <Domenic> | :( why are promises so hard to use from C++ |
| 14:16 | <mounir> | hmm, I would prefer to have the promise being aware of the change before the event |
| 14:16 | <mounir> | Domenic: it's not because of promises, it's because of locking |
| 14:16 | <Domenic> | oh that's good to hear |
| 14:16 | <mounir> | Domenic: promises are not hard to use |
| 14:16 | <annevk> | you change the value, resolve the promise, dispatch the event |
| 14:16 | <Domenic> | they are hard to use in Blink, apparently. |
| 14:16 | <annevk> | in one task |
| 14:17 | <annevk> | at the start of the task the event listeners will run |
| 14:17 | <annevk> | at the end of the task any registered promise observers will run |
| 14:17 | <mounir> | Domenic: I work on Blink... |
| 14:17 | <annevk> | (as a microtask) |
| 14:17 | <Domenic> | mounir: I'm so confused |
| 14:17 | <Domenic> | mounir: also, hi coworker! |
| 14:17 | <mounir> | ahaha |
| 14:18 | <Domenic> | mounir: https://github.com/slightlyoff/ServiceWorker/issues/223#issuecomment-46138414 is what I was referring to I guess |
| 14:18 | <annevk> | the way promise.then() works you can't really notify the promise observers before the event |
| 14:18 | <Domenic> | but yes, annevk's spec text will give the observable order you desire |
| 14:18 | <mounir> | annevk: I prefer to have the promise fire before so it's clear that the orientationchange happens because of the lock |
| 14:18 | <Domenic> | since events are synchronous and promises are asynchronous |
| 14:18 | <annevk> | we had this thing about synchronous invocation of promise observers but that died |
| 14:18 | <Domenic> | wait, i'm confusing myself |
| 14:18 | <annevk> | promise observers are asynchronous |
| 14:19 | <Domenic> | annevk, your spec text will result in the wrong observable order, right? |
| 14:19 | <annevk> | or whatever the term is |
| 14:19 | Domenic | clearly needs more coffee |
| 14:19 | <annevk> | Domenic: event listeners first, then the promise in the end-of-task microtask |
| 14:19 | <Domenic> | annevk: right, which is the opposite of what mounir wants |
| 14:20 | <annevk> | you can't get what mounir wants |
| 14:20 | <Domenic> | yes you can |
| 14:20 | <mounir> | annevk: I want ice cream! |
| 14:20 | <annevk> | mounir: we have some here ;) |
| 14:20 | <Domenic> | resolve p with this.orientation. Upon fulfillment of p, fire event "orientationchange"... |
| 14:20 | <annevk> | not upon fulfillment, upon p firing it's observers |
| 14:21 | mounir | dies a little bit inside |
| 14:21 | <annevk> | that could work, do we have easy language for that? |
| 14:21 | <mounir> | that will be even harder to implement |
| 14:22 | <Domenic> | annevk: "upon fulfillment" is the same as "upon p firing it's observers" :) https://github.com/w3ctag/promises-guide#reacting-to-promises |
| 14:22 | <annevk> | Domenic is suggesting "value = x; promise.resolve(x); promise.then(dispatchEventForValueChange)" |
| 14:22 | <annevk> | which seems like a nice pattern for when you have both promises and events |
| 14:22 | <annevk> | but a bit more icky I guess since promises are JavaScript and everything else is C |
| 14:27 | <mounir> | could we do something like this: |
| 14:28 | <mounir> | when a lock is done we resolve the promise with a value |
| 14:28 | <mounir> | when orientation changes, we update screen.orientation and queue a task to fire an event |
| 14:28 | <mounir> | that way, we have screen.orientation changed, the promise fires then the event, right? |
| 14:29 | <Domenic> | domain question: what is the diffference between "lock is done" and "orientation changes"? |
| 14:29 | <mounir> | Domenic: those are different concepts |
| 14:29 | <mounir> | that's why implementation-wise it's painful to link them |
| 14:29 | <Domenic> | ok. but in the lockOrientation() case, how are they connected? |
| 14:29 | <Domenic> | I see |
| 14:29 | <mounir> | Domenic: I can change the orientation by turning my phone |
| 14:29 | <mounir> | Domenic: I can lockOrientation() twice in a row |
| 14:30 | <mounir> | and have an orientationchange that will not resolve the lock |
| 14:30 | <mounir> | then the next one will |
| 14:30 | <Domenic> | what does "resolve the lock" mean |
| 14:30 | <mounir> | Domenic: the lock is applied |
| 14:30 | <Domenic> | hmm hmm |
| 14:31 | <Domenic> | OK here is a hack that would work, I think |
| 14:31 | <Domenic> | And minimizes complexity and coupling |
| 14:31 | <Domenic> | lockOrientation(): when lock is done, resolve the promise |
| 14:32 | <Domenic> | when orientation changes: change this.orientation, queue a microtask to queue a task to fire an event |
| 14:32 | <Domenic> | and define ordering so that "lock is done" happens after "orientation changes" |
| 14:33 | <mounir> | hmm |
| 14:33 | <mounir> | that's roughly what I said above, isn't it? ;) |
| 14:33 | <mounir> | I guess we agree |
| 14:33 | <Domenic> | upon re-reading, I think it is :) |
| 14:33 | <mounir> | \o/ |
| 14:34 | <Domenic> | it might be important to say "queue a microtask to queue a task" instead of just "queue a task" |
| 14:34 | <Domenic> | I would have to re-check how browser turns are specced to be sure |
| 14:34 | <mounir> | I will ask you to review that the PR ;) |
| 14:34 | <Domenic> | In either case a non-normative note about the intended ordering should probably be included |
| 14:34 | <mounir> | but before that, I shall have some fun and implement this... :) |
| 14:35 | <Domenic> | :D |
| 14:36 | <mounir> | Domenic, annevk: thanks for your help :) |
| 14:36 | <Domenic> | mounir: thanks for caring about getting it right! |
| 14:52 | annevk | is still not sure he grasps the complete flow, will review later |
| 14:53 | <annevk> | Domenic: fetch() now no longer handles content codings automatically |
| 14:53 | <Domenic> | annevk: sweet |
| 14:53 | <annevk> | Domenic: still handles transfer codings and TLS of course |
| 14:53 | <annevk> | that was a tough change, but was sorta required anyway to fix progress events |
| 14:55 | <annevk> | JakeA: Fetch now has these open issues: structured cloning, and behavior of method |
| 14:55 | <annevk> | Domenic: I guess I should also offer some kind of 304-opt-out flag |
| 14:56 | <Domenic> | annevk: I guess I should continue along the structured cloning track |
| 14:56 | <Domenic> | annevk: modulo writing things up a bit more formally, it seems like cloning promises between realms works fine. time to think about cloning them to disk. |
| 14:57 | <annevk> | it's not blocking shipping most likely, but solving it would be good to make sure we don't end up with surprises later |
| 14:57 | <annevk> | I liked the message channel solution |
| 14:57 | <Domenic> | annevk: re 304, isn't the opt-out just not sending the conditional GET headers? |
| 14:58 | <annevk> | Domenic: so UAs add such headers, the opt out would be not getting a 200 back |
| 14:58 | <Domenic> | hmm |
| 14:58 | <annevk> | there's some magic post-processing going on there |
| 14:58 | <Domenic> | node's http client is much more raw in this respect, but that's not necessarily a good thing |
| 14:59 | <Domenic> | i.e. http.get() doesn't add any headers you don't pass, and a 304 is just a 304, it doesn't get converted to a 200 |
| 14:59 | <annevk> | Note that header setting in http://fetch.spec.whatwg.org/#http-network-or-cache-fetch is XXX |
| 14:59 | <annevk> | It doesn't set User-Agent, Date, etc.? |
| 14:59 | <Domenic> | I think it sets Date since that's required by the spec |
| 15:00 | <Domenic> | will check in a minute |
| 15:00 | <Domenic> | on the flip side, nobody has yet to my knowledge written a good browser-quality cache for node that handles that stuff automatically, so the raw-ness kind of sucks for a lot of use cases. |
| 15:00 | <annevk> | We can't do raw |
| 15:00 | <annevk> | But we could come close if that's desired |
| 15:00 | <annevk> | Data from node would be great |
| 15:01 | <annevk> | Domenic: maybe file a ticket with the data? on SW is fine, I'll link it al together |
| 15:01 | <Domenic> | yeah we should have this discussion on a ticket |
| 15:02 | <JakeA> | annevk: where are those issues documented? |
| 15:02 | <annevk> | JakeA: in the spec |
| 15:03 | <annevk> | JakeA: see the red markers |
| 15:03 | <annevk> | JakeA: there's also SW issues filed for them |
| 15:03 | <annevk> | JakeA: but nobody is looking at old SW issues other than me I think :/ |
| 15:04 | annevk | still has to check if the security model with SW and Response/Request is correct |
| 15:06 | <JakeA> | annevk: a lot of that is my fault, my time got swallowed with I/O stuff. That's done at the end of this week. |
| 15:25 | <annevk> | JakeA: nah man, there's like fifteen people involved in this effort |
| 15:25 | <annevk> | JakeA: that video was fun btw |
| 15:41 | <Domenic> | http://www.w3.org/TR/encoding/ is not bad, as plagarism goes |
| 15:42 | <Domenic> | the only improvements I could think of would be adding language along the lines of "this document is obsolete and is intended for use only by patent lawyers", and making the red box float in the center of the screen, not bottom. |
| 15:45 | gsnedders | thinks someone just needs to come up with some reasonable RF policy for other specs |
| 15:45 | <gsnedders> | but the problem is getting people to agree to it |
| 16:38 | <annevk> | Hixie: that email :-) |
| 16:38 | <annevk> | so true |
| 16:40 | <Hixie> | so tired of having to explain this over and over |
| 16:40 | <caitp> | explain it again, :) |
| 16:42 | <annevk> | Hixie: at some point Domenic will use his magic and capture it all in GitHub repo or some YouTube video |
| 16:47 | <jgraham> | The one about certification? |
| 16:50 | <annevk> | I guess the one about spec development |
| 16:50 | <annevk> | Well, hoping |
| 16:50 | <jgraham> | Which one? |
| 16:53 | <Hixie> | i created this, with respect to the meta thing yesterday: http://wiki.whatwg.org/wiki/Best_Practices_for_Implementors |
| 16:57 | <annevk> | jgraham: I thought you were rhetorical |
| 16:58 | <jgraham> | annevk: I'm very confused |
| 16:59 | <jgraham> | I honestly don't know which email you were reading :) |
| 17:00 | <annevk> | jgraham: ooh, I thought you were making a comment about the fictional GitHub repo or YouTube video |
| 17:00 | <annevk> | jgraham: yes this started with that email |
| 17:00 | <jgraham> | which email?! |
| 17:00 | <annevk> | about certification |
| 17:00 | <jgraham> | Oh right |
| 17:00 | <jgraham> | Yeah |
| 17:01 | <annevk> | Ooh look, a brand-color extension has been proposed |
| 17:01 | <jgraham> | So unfortunatley I think there's a >99% chance that email won't change Glenn's opinion and about a 90% chance it will make him think "Hixie is a clown who doesn't understand the requirements of Real Businesses" |
| 17:02 | <annevk> | That reminds me of the famous Boeing example that always came up during TPAC |
| 17:02 | <Domenic> | Hixie: I liked the email but I think it would have been stronger if you dropped the "pointless" from "pointless certification" |
| 17:02 | <Domenic> | oh what Boeing example, sounds fun |
| 17:02 | <jgraham> | Yeah, the "pointless" was not helpful |
| 17:02 | <Hixie> | Domenic: what is the point of certifying a WebIDL implementation? |
| 17:02 | <annevk> | Domenic: that Boeing was using old browsers and that therefore standards were important, it didn't make any sense |
| 17:03 | <jgraham> | Certification is not, in itself, pointless |
| 17:03 | <annevk> | Domenic: but somehow people loved it and it always got cheers |
| 17:03 | <Domenic> | Hixie: no point for us, but for Glenn, or more importantly Glenn's pointy-haired boss, maybe there is one |
| 17:03 | <Domenic> | annevk: O_O |
| 17:03 | <Hixie> | jgraham: right, i was trying to explicitly distinguish the useful certification from the kind of certification we're talking about here |
| 17:03 | <jgraham> | It might not be the optimal strategy for a platform like the web where rapid improvement is valued over interop |
| 17:03 | <SamB> | Hixie: isn't the "pointless" basically pointless? |
| 17:03 | <jgraham> | Hixie: It sounds like you are describing certification as inherently pointless |
| 17:03 | <SamB> | I mean how many certifications aren't? |
| 17:04 | <jgraham> | SamB: Well I like to know that my plug won't electrocute me… |
| 17:04 | <Hixie> | jgraham: i was just commenting on this specific kind of certification |
| 17:04 | <SamB> | oh, so we're including non-software certifications now? |
| 17:04 | <SamB> | maybe I should say, non-general-purpose-software certifications |
| 17:04 | <Hixie> | SamB: well presumably e.g. a doctor getting certified as "able to doctor" is not pointless |
| 17:05 | <jgraham> | SamB: Well the context is really TV people who have a background in hardware where certification is not pointless |
| 17:05 | <SamB> | ah |
| 17:05 | <Hixie> | SamB: presumably flight software being certified as "able to not crash the rocket into the ground at t=0" is also not pointless |
| 17:05 | <SamB> | Hixie: yeah, hense my amendment to include more hyphenated terms ;-) |
| 17:06 | <jgraham> | They extrapolate that experience to the web and try to go around making "certified" versions of all the standards |
| 17:06 | <jgraham> | Which are usually a snapshot from some time, with a few added features and some more removed and a testsuite that you're supposed to conform to |
| 17:06 | <SamB> | Hixie: lets also make sure to mention the obligatory hospital equipment |
| 17:07 | <SamB> | like those IV regulators or whatever |
| 17:08 | <jgraham> | Certification is useful any time there's a significant harm to something being misrepresented |
| 17:08 | <SamB> | yeah |
| 17:08 | <jgraham> | Which is pretty often |
| 17:08 | <SamB> | but it's not so useful when the software changes every few weeks |
| 17:09 | <jgraham> | Right. There is a downside too, which is calcification |
| 17:09 | <SamB> | I mean, not unless you can get costs down to where it gets certified every damn release, BEFORE release |
| 17:09 | <jgraham> | Anyway for the web it isn't going to happen, because people don't value interop that much |
| 17:10 | <SamB> | which seems really unlikely for software that involves a lot of C, C++, and JavaScript |
| 17:12 | <Hixie> | i think people on the web value interop very much, it's just that the standards are huuuuuge, and not yet done |
| 17:13 | <jgraham> | But they won't ever be "done" |
| 17:13 | <Hixie> | and won't be done for a long time, because we started with very poor specs and thus very divergent implementations |
| 17:13 | <Hixie> | and it's gonna take a long time for them to converge |
| 17:13 | <Hixie> | i think one could imagine a time decades hence where you could freeze a spec before adding more new features, and say, this is what browsers must implement to render today's content |
| 17:13 | <SamB> | Hixie: also people keep insisting on new features |
| 17:13 | <Hixie> | (i don't think it'd be particularly useful, but that's a separate issue) |
| 17:14 | <Hixie> | the problem is right now, and for the forseeable future, there's no chance of the specs being good enough for them to describe exactly what browsers need to do |
| 17:15 | <jgraham> | I think you can imagine that time, but I don't think it will happen. There's a tradeoff between interop and evolution, and as long as the former is good enough people always prefer the latter |
| 17:15 | <jgraham> | This isn't even a bad thing (it helps keep the platform relevant) |
| 17:16 | <Hixie> | yeah it's quite possible that we won't reach this point before the web is irrelevant |
| 17:16 | <jgraham> | But it does mean that it's an uphill battle to get people to invest resources in interop, particularly for features that are seen as "Good Enough" |
| 17:17 | <SamB> | Hixie: how will the web be irrlevent? |
| 17:17 | <annevk> | jgraham: it's still a bit unclear to me how in the current climate I'm allowed to work on improving interoperability on low-level architecture |
| 17:18 | <jgraham> | annevk: Because you are effective at selling it as needed for $new_shiny? |
| 17:19 | <annevk> | Yeah, that works I guess |
| 17:19 | <Hixie> | SamB: something is eventually going to replace the web as the world's information store. |
| 17:20 | <annevk> | Took me a while to figure out that was happening though, I was just trying to fix problems |
| 17:20 | <SamB> | Hixie: I guess I'm wondering if will have a new name |
| 17:20 | <Hixie> | SamB: LCARS, maybe? |
| 17:21 | <SamB> | isn't that a HIG and/or toolkit? |
| 17:21 | <SamB> | I do like the idea of being able to customize my menus and controls and have them follow me around, though |
| 17:22 | <IZh> | Hi. What about sending document loading progress events to parent document? Or at least providing such interface to query the status and percentage of completeness? |
| 17:22 | <Hixie> | SamB: "technically" LCARS is an information retrieval system, though people often refer to the UI as LCARS |
| 17:24 | <Hixie> | SamB: but e.g. "hey siri, i need the expansion for the abbreviation LCARS" is probably close to where we're headed, and it's not clear that the web need exist in that world, at least not in anything like the form we have today |
| 17:24 | <IZh> | Of course, if there is a parent. |
| 17:25 | <jgraham> | Hixie: That seems like a very strange statement. I mean you are just talking about a UI, which doesn't say much about the backend information store |
| 17:27 | <jgraham> | It seems like the UI you describe is a) only a small subset of all the possible interaction UIs we will require and b) quite implementable on top of the web as it exists |
| 17:28 | <SamB> | jgraham: well, what is the backend information store of the web anyway? |
| 17:29 | <jgraham> | A collection of hyperlinked text documents, in theory |
| 17:29 | <jgraham> | In practice these days, it's closer to a set of hyperlinked applications written in js |
| 17:30 | <SamB> | one does hope that we can get something slightly less opaque next time around |
| 17:30 | <jgraham> | What makes you think that this would be a a success? |
| 17:31 | <jgraham> | It seems like it's the semantic web problem. They assume that people want to know the answers to questions like "what's the expansion of LCARS" whereas people actually want to know things like "are there any interesting things happening today" or "can I find someone to have a relationship with" |
| 17:32 | <SamB> | I mean, obviously, there's nothing to stop things being just as opaque as they tend to be now, but it might be nice if that wasn't nearly mandatory for anything of any complexity |
| 17:32 | <jgraham> | I guess "siri get me a girlfriend" is a possible future, but it sounds quite dystopian |
| 17:33 | <IZh> | jgraham: The future is: Siri, will you be my girlfriend? ;-) |
| 17:33 | <SamB> | IZh: that's the future, is it? |
| 17:34 | <SamB> | IZh: I assume you aren't hoping that stuff you asked about would work cross-origin |
| 17:34 | <caitp> | the dystopia exists, just around the corner there's some kid looking to make millions making some combination tinder/snapchat and marketing it to 13 year olds |
| 17:34 | <SamB> | I mean, at least, not without something like CORS saying it's okay |
| 17:35 | <annevk> | https://twitter.com/jaffathecake/status/482215293985783810 haha |
| 17:35 | <IZh_> | SamB: of course |
| 17:37 | <SamB> | jgraham: Hmm, yeah, I guess the "semantic web" people are hoping to bring such transparency to the web we already have, aren't they? |
| 17:42 | <Ms2ger> | link rel=script again? |
| 17:42 | Ms2ger | ignores this thread, assumes Hixie will close it out quickly |
| 17:43 | <SamB> | why would anyone think that might be useful? |
| 17:43 | <Ms2ger> | It's consistent! |
| 17:44 | <caitp> | they're right, it would be better for everyone to start shrinking the language rather than growing it |
| 17:44 | <Hixie> | jgraham: yeah, i wouldn't be surprised if it was built on top of the web as we know it |
| 17:45 | <Hixie> | jgraham: but simultaneously, large parts of it might become irrelevant (e.g. navigation, scripting) |
| 17:45 | <SamB> | Hixie: it does seem more likely than building it on top of Emacs, yes |
| 17:45 | <Hixie> | jgraham: anyway, this is all conjecture |
| 17:50 | <Ms2ger> | Most often use for tag <script> is to include external script through |
| 17:50 | <Ms2ger> | <script src="somecdn.example/jquery.js">, or alike. May be we could add |
| 17:50 | <Ms2ger> | rel="script" to <link> tag with same behaviour as <script> with src. |
| 17:50 | <Ms2ger> | It's similiar to stylesheets: we can link external stylesheets via <link> |
| 17:50 | <Ms2ger> | and include CSS directly on page with <style> tag. |
| 17:50 | <Ms2ger> | SamB, ^ |
| 17:51 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/347 |
| 17:51 | <annevk> | Domenic: shall I file an issue on that header thing? |
| 17:52 | <caitp> | > remove primitives from the language, simplify it >> allow developers to grow the language with custom elements >>> eventually profit |
| 17:52 | <SamB> | Ms2ger: so basically they have hobgoblin-infested, small minds? |
| 17:52 | <Ms2ger> | No comment |
| 17:52 | <SamB> | oh wait, that wouldn't be an example of false consistancy though would it |
| 17:52 | <annevk> | I once thought that would be cool |
| 17:53 | <Ms2ger> | I probably did too |
| 17:53 | <SamB> | just "too late" realyl |
| 17:53 | <annevk> | Because then you could do Link: <script.js>; rel=script |
| 17:53 | Ms2ger | liked XHTML2 at one point |
| 17:53 | <annevk> | Making something like http://annevankesteren.com/robots.txt even more impressive |
| 17:53 | <annevk> | XBL, alas |
| 17:53 | <annevk> | Also, separation of script and markup |
| 17:54 | <Ms2ger> | "Huge line for a talk about mobile web performance. The mobile web is not dead! #io14" |
| 17:54 | <Ms2ger> | Sounds like people want to know if their code is going to be removed |
| 17:54 | <SamB> | is the mobile web somehow different from the normal web? |
| 17:54 | <caitp> | it's the one people actually use |
| 17:55 | <SamB> | well, I mean, my dumbphone's browser is some kind of sick joke |
| 17:55 | <SamB> | but I was under the impression that I was using more-or-less the same web on my aging desktop as everyone else, only much, much slower |
| 18:01 | <Domenic> | JakeA: why is my face there |
| 18:01 | <Domenic> | annevk: yes please |
| 18:02 | <caitp> | unlike the desktop, where you can do pretty much anything without any significant performance hits, people end up optimizing web apps for a specific handset, because maybe css doesn't do a good enough job so lets emulate gradiants in a canvas or invent some idea that flat uis are attractive or something --- and then once all of that is done they say "no lets not make this a web app, lets make this a packaged app so we |
| 18:02 | <caitp> | can use native APIs because webRTC or geolocation don't exist yet", etc |
| 18:02 | <caitp> | it ends up being pretty different |
| 18:06 | <annevk> | Domenic: https://github.com/slightlyoff/ServiceWorker/issues/348 |
| 18:06 | <Domenic> | annevk: sweet, queued for tonight or tomorrow. |
| 19:13 | <annevk> | marcosc: why is that not a wiki page? |
| 19:14 | <annevk> | GH repo seems overkill |
| 19:24 | <Domenic> | honestly sending pull requests is more convenient than registering for that wiki |
| 19:25 | <Domenic> | plus you get issue tracking |
| 19:31 | <marcosc_> | annevk, what Domenic said |
| 20:23 | <Hixie> | smaug____: iirc the idea is that if the browser wants to make navigating to an image bring up an image editor, or whatever, then it's not really our place to say that's not valid |
| 20:35 | <IZh> | In the section "Submit Button state" there is the fingerprint icon. How Submit button could be used to fingerprint a user? There are no additional notes about it in this section. |
| 20:36 | <IZh> | http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#submit-button-state-%28type=submit%29 |
| 20:40 | <IZh> | Hixie? |
| 20:41 | <Domenic> | interesting question |
| 20:41 | <Hixie> | check the value of the .value idl attribute when the element has no value content attribute |
| 20:41 | <Hixie> | (gives you a few bits, but they're redundant with the UA string) |
| 20:41 | <Hixie> | (and the language) |
| 20:43 | <IZh> | Hixie: Thanks for explanation. May be few words should be added about it. At least pointing to .value attribute. |
| 20:43 | <Hixie> | maybe. file a bug :-) |
| 20:44 | <Domenic> | why would the .value attribute matter... i don't get it... |
| 20:44 | <Hixie> | try it :-) |
| 20:46 | <Domenic> | it's "Submit Query" in IE, but "" in Chrome and Firefox |
| 20:46 | <Domenic> | is this just a matter of fingerprinting via some browsers not following the spec? |
| 20:47 | <Domenic> | it seems like the value of .value is unspecced for submit buttons |
| 20:48 | <IZh> | Filed. :-) |
| 20:49 | <Hixie> | Domenic: it's specced to be UA-dependent, which is the fingerprint vector |
| 20:49 | <Hixie> | (i'm surprised you get "") |
| 20:49 | <Domenic> | Hixie: how I read the spec was that the label is UA-dependent, as long as .value was unset |
| 20:49 | <Domenic> | i didn't see a spec for .value |
| 20:50 | <IZh> | Why the bug filing form has no Author field? ;-)) |
| 20:50 | <Domenic> | Hixie: actually following the link to "default" it seems like the spec says it should be "" |
| 20:50 | <IZh> | May be in expanded version. |
| 20:51 | <Hixie> | IZh: if you're logged into the spec annotation system, the author is automatically entered |
| 20:51 | <IZh> | Hixie: Oh! Good. |
| 20:52 | <Hixie> | Domenic: hm, you're right. I guess it's actually the button width that you'd have to look at to get the fingerprinting bits, not the attribute value |
| 20:52 | <Domenic> | Hixie: ah right, that'd do it. makes sense. |
| 20:56 | <IZh> | Revalidated the spec. Only 3 minor errors: still has one broken link to W3C's css-font-load-elements and 2 accessibility errors about iframes without "title" attributes. |
| 20:56 | <TabAtkins> | Hixie: Ah, if you have a link to font-load-events, switch it font-loading. |
| 20:57 | <Hixie> | there's a bug on that i think |
| 20:57 | <Hixie> | sorry about not doing any fixes in recent days. i'm working on my pipeline. |
| 20:57 | <TabAtkins> | Np. |
| 20:57 | <Hixie> | once that's done hopefully my productivity will be higher. |
| 20:57 | <Hixie> | (than before, i mean, not than now, where it's zero!) |
| 21:02 | <MikeSmith> | IZh: 2 accessibility errors about iframes without "title" attributes |
| 21:02 | <MikeSmith> | ? |
| 21:03 | <MikeSmith> | IZh: which checker reports errors about those? |
| 21:03 | <IZh> | CSE HTML validator. |
| 21:03 | <Hixie> | an overzealous one, presumably :-) |
| 21:04 | <IZh> | It says: [70] The "iframe" element requires the "title" attribute to label the frame, describe the contents, and facilitate frame identification so users can determine which frame to enter. Frame titles must be meaningful. For example, "Table of Contents", "Where the content is displayed", and "Sitewide navigation bar" (or simply "Navigation"). Visit http://www.w3.org/TR/WCAG20-TECHS/H64 for... |
| 21:04 | <IZh> | ...more information. [A, 2.4.1; H64] [A, 4.1.2; H64] |
| 21:05 | <MikeSmith> | IZh: "users can determine which frame to enter"? for an iframe? |
| 21:06 | <Hixie> | many ATs have a pretty poor user experience around iframes |
| 21:06 | <Hixie> | they basically offer them as black boxes that the user can chose to enter or not, given the title |
| 21:06 | <MikeSmith> | oh |
| 21:07 | <MikeSmith> | that does sound bad |
| 21:07 | <Hixie> | (instead of doing what the HTML spec basically requires, which is to treat them as transparent transclusions) |
| 21:07 | <MikeSmith> | yeah |
| 21:08 | <Hixie> | careful, criticising ATs means you hate disabled users |
| 21:08 | <MikeSmith> | man that has to be really annoying for the users |
| 21:08 | <IZh> | Anyway, there are 2 iframes without titles in the spec. |
| 21:09 | <MikeSmith> | Hixie: I love everybody |
| 21:09 | <MikeSmith> | IZh: nobody in real universe puts titles on iframes |
| 21:10 | <IZh> | MikeSmith: No problem. :-) |
| 21:11 | <MikeSmith> | I wonder what NVDA does with iframes. I mean, if it also does the "offer them as black boxes that the user can chose to enter or not, given the title" thing |
| 21:11 | <MikeSmith> | I would hope at least NVDA doesn't do that |
| 21:11 | <MikeSmith> | or Voiceover |
| 21:18 | <IZh> | "Internal Error: Oops. That was not supposed to happen. A bug manifested itself in the application internals. Unable to continue. Sorry. The admin was notified." I have crashed the validator.nu ;-) |
| 21:22 | <MikeSmith> | IZh: you didn't crash it :) |
| 21:22 | <MikeSmith> | that's just an uncaught exception |
| 21:22 | <MikeSmith> | but thanks for finding it |
| 21:23 | <MikeSmith> | do you have a URL for a doc that I can test with, to reproduce that |
| 21:23 | <MikeSmith> | ? |
| 21:23 | <MikeSmith> | or a minimal test case |
| 21:23 | <IZh> | It can't handle port nombers >= 65536 ;-) |
| 21:23 | <IZh> | http://validator.whatwg.org:65536/ |
| 21:24 | <MikeSmith> | ah that may be in the library code that we use for checking URLs |
| 21:24 | MikeSmith | checks |
| 21:28 | <MikeSmith> | IZh: java.lang.NullPointerException at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:721) |
| 21:28 | <IZh> | Somebody has to check port number. :-) |
| 21:30 | <IZh> | Also one probably potential security issue: When you validating http://localhost/ it says 404. But not access denied or so. I mean that the validator could be probably used for scanning internal network. |
| 21:31 | <IZh> | Probably validator should ban access to private IP ranges. |
| 21:31 | <IZh> | Or I could try to validate some web-server status page or so (by enabling "Show Source"), if any. |
| 21:33 | <IZh> | And there is one way to abuse the validator: recursion. ;-) You can ask the validator to validate the results of validating the results of validating of some page. :-) |
| 21:34 | <IZh> | Of course, with enabled "Show Source" ;-) |
| 21:35 | <IZh> | I think there should be a restriction on validating URL when validating itself. |
| 21:36 | <MikeSmith> | IZh: please file bugs |
| 21:37 | <MikeSmith> | I've talked about some of these things with Henri already and we didn't have any clever ideas |
| 21:38 | <IZh> | MikeSmith: Where is the validator's bug reporting page? |
| 21:38 | <IZh> | Found it. |
| 21:38 | <MikeSmith> | but I think we're essentially not doing anything different than you could do with a browser or with lynx or some other http UA |
| 21:46 | <IZh> | One more internal error. Select "File Upload" but do not provide any file, enable "Show Outline" and click Validate ;-) |
| 21:51 | <IZh> | I think it can't make outlines for empty documents. |
| 21:52 | <MikeSmith> | oh that's kinda silly |
| 21:53 | <MikeSmith> | I guess I should fix that |
| 21:54 | <MikeSmith> | hmm validator.w3.org/nu doesn't have that issue |
| 21:55 | MikeSmith | checkes qa-dev.w3.org:8888 |
| 21:56 | <IZh> | Because it forbids to submit the form without file. |
| 21:57 | <IZh> | But it has the port number issue. |
| 21:58 | <MikeSmith> | can't reproduce it at http://qa-dev.w3.org:8888 |
| 21:58 | <IZh> | 8888 is less than 65536 ;-) |
| 21:58 | <MikeSmith> | which is built from the latest soruces |
| 21:59 | <IZh> | Try 65536 or greater port number |
| 21:59 | <MikeSmith> | IZh: I mean the outline problem |
| 21:59 | <IZh> | Try on http://validator.nu/ |
| 21:59 | <MikeSmith> | and I mean I have an instance of the validator at http://qa-dev.w3.org:8888 |
| 22:00 | <MikeSmith> | IZh: yeah I understand but I don't have access to the error logs for http://validator.nu/ |
| 22:00 | <IZh> | Hmmm... No error. |
| 22:00 | <MikeSmith> | whereas I do for http://qa-dev.w3.org:8888 |
| 22:00 | <MikeSmith> | yeah |
| 22:00 | <MikeSmith> | the code running at http://validator.nu/ is a little behind the current sources |
| 22:00 | <MikeSmith> | so maybe I made a fix in the meantime, I dunno |
| 22:00 | <IZh> | I see. |