| 01:55 | <roc> | Anyone know why <img style="position:absolute; background-color:blue; left:10%; top:10%; right:10%; bottom:10%"> gives a 0x0 size of the <img> element in Chrome? This seems like an extremely basic bug |
| 01:57 | roc | wonders if that's actually correct |
| 01:59 | <roc> | looks like it is! |
| 02:30 | <Hixie> | as far as i can tell according to http://www.w3.org/2013/09/normative-references, the w3c's policy is that the w3c's own specs aren't good enough to be normatively referenced :-) |
| 02:38 | <MikeSmith> | Hixie: I think that doc's not been updated in a while but if you have suggestions I think plh would genuinely be interested |
| 02:38 | <MikeSmith> | the thing is that plh has a stronger interest than most anybody else in seeing the W3C have a saner policy for normative references |
| 02:39 | <MikeSmith> | since he's the one that's responsible for trying to get most of the specs through the W3C process |
| 02:39 | <MikeSmith> | specs for the web platform at least |
| 02:41 | <MikeSmith> | and the main thing that blocks many of the specs progressing right now is not any technical issues but instead this references problem |
| 02:43 | <SamB> | is that blocked on a patent policy? |
| 02:45 | <Hixie> | MikeSmith: that doc is all about "stable references" and (indirectly through a reference it itself has) "due process" and "broad consensus" and so on |
| 02:45 | <Hixie> | MikeSmith: a variety of things which the w3c doesn't actually do, and which are in any case not good ways to design technologies |
| 02:46 | <Hixie> | MikeSmith: there should really be very few concerns when referencing another spec. Prime amongst them: "Is the document being actively maintained?" and "Does the document accurately describe what implementations must do to obtain interoperability with deployed content?" |
| 02:46 | <MikeSmith> | I guess I filter out those parts. I'm more interested in tryin to make the actual requirements in there reflect what's important |
| 02:46 | <SamB> | process is probably a good idea for GRs and CTTE decisions; other than that I dunno ... |
| 02:47 | <MikeSmith> | Hixie: yeah, like that |
| 02:47 | <MikeSmith> | Hixie: it should have that kind of wording |
| 02:47 | <SamB> | Hixie: would it be a big issue if some spec were frozen? |
| 02:47 | <Hixie> | SamB: you mean like on the TR/ page? yeah... |
| 02:47 | <SamB> | like, I dunno, pretend the GIF spec actually specified everything important 20 years ago |
| 02:49 | <Hixie> | SamB: it'd still need to be updated over the years to track changes in frame length clamping, e.g. |
| 02:49 | <SamB> | hmm |
| 02:51 | <MikeSmith> | Hixie: the thing is, as I think you know, we don't really have a binding policy on this. Or really, the policy is, the Director decides whether something can transition or not, and if you can make a convincing case to the director for some individual spec, the director OKs it |
| 02:51 | <MikeSmith> | Hixie: but the director responds to reason and sound arguments, and things like "Is the document being actively maintained?" |
| 02:51 | <MikeSmith> | ... are sound |
| 02:51 | <MikeSmith> | and I don't think some of those things have been well-articulated by anybody to the director so far |
| 02:51 | <MikeSmith> | and "Does the document accurately describe what implementations must do to obtain interoperability with deployed content?" too |
| 02:52 | <Hixie> | "the director decides" is what people say is the worst part of the whatwg |
| 02:52 | <SamB> | I didn't know TimBL was at the WHATWG |
| 02:52 | <Hixie> | different director in the whatwg's case |
| 02:52 | <MikeSmith> | WGs should not be allowed to reference "stable" specs that don't match implementation realities -- unless the reference is to say, We're violating the following parts of this out-of-date spec |
| 02:52 | <Hixie> | (different director per spec, even) |
| 02:53 | <SamB> | I thought they were called editors |
| 02:53 | <Hixie> | a rose by any other name... |
| 02:53 | <SamB> | would be just as prickly? |
| 03:08 | <MikeSmith> | hayato: I don't find Kenji on IRC but been wanting to ask what the plans are for his open PRs at https://github.com/w3c/web-platform-tests/pulls/KenjiBaheux |
| 03:09 | <MikeSmith> | hayato: those have all mostly been sitting open with no activity for months and have kinda gone stale at this point |
| 03:09 | <hayato> | MikeSmith: These PRs are waiting for Kenji's response? |
| 03:09 | <hayato> | MikeSmith: Let me take a look |
| 03:10 | <MikeSmith> | yeah I think they're waiting on Kenji |
| 03:10 | MikeSmith | looks too to confirm |
| 07:07 | <zcorpan> | MikeSmith: the mq ref bug seems like make work. If you think it is urgent ask hixie to prioritize it |
| 08:17 | <annevk> | I like how 1386 mocks 386 a bit |
| 09:46 | <Ms2ger> | So who thought setting up a public-editing-tf mailing list was a good idea? |
| 09:49 | <darobin> | Ms2ger: pretty much everyone involved in the editing discussion |
| 09:50 | <darobin> | and, judging by the number of people who wrote to me saying "thanks for removing that incomprehensible discussion from WebApps", quite a few WebApps people too :) |
| 10:00 | <Ms2ger> | Yeah, defining things in silos always works out well |
| 10:00 | <Ms2ger> | Good that I wasn't hoping for that to go anywhere |
| 10:06 | <roc> | Ms2ger: surely you're too young to be this bitter |
| 10:06 | <Ms2ger> | Standards work ages one quickly |
| 10:07 | <roc> | hmm, how old does that make me? |
| 10:07 | <Ms2ger> | being-cited-in-textbooks-old :) |
| 10:23 | MikeSmith | dials down the Bitterness setting on the Ms2ger bot, dials up the Smoothness |
| 11:41 | <tobie> | Domenic: #popcorn |
| 11:51 | <annevk> | tobie: what did he do? |
| 11:51 | <tobie> | annevk: he reference the WebIDL thread above. :) |
| 11:51 | <tobie> | *referenced |
| 11:51 | <annevk> | ah |
| 12:05 | <annevk> | So with Symbols we could make a lot of things extensible |
| 12:06 | <annevk> | E.g. send() and fetch() both take a thing of sorts and extract bytes and a MIME type out of it (and maybe an encoding) |
| 12:06 | <annevk> | If we defined @@fetchExtract or some such that returns an object with the relevant information, that would totally work |
| 13:37 | <smaug____> | does the spec say something about image documents |
| 13:37 | <smaug____> | I mean, what kind of content the document should have, if just an image is loaded to a browsing context ? |
| 13:37 | <smaug____> | (I think it did, but can't find it now) |
| 13:38 | <annevk> | smaug____: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-media |
| 13:39 | <smaug____> | thanks |
| 13:39 | <smaug____> | (history.html o_O) |
| 13:40 | <annevk> | smaug____: artefact of splitting |
| 14:19 | <zewt> | help, working in a new codebase and these guys use hard tabs, so the code is all randomly unformatted and unreadable |
| 14:38 | <annevk> | I wonder who is implementing networking in Servo |
| 14:38 | <annevk> | And whether they are making use of http://wiki.whatwg.org/wiki/HTTP and such |
| 14:41 | <SimonSapin> | annevk: we (Servo) use rust-http, which is built mostly by Chris Morgan. I don’t know what specs it’s based on. |
| 14:42 | <SimonSapin> | annevk: also, how does that wiki page relate to the "httpbis" RFCs? https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead |
| 14:43 | <annevk> | SimonSapin: I believe most of it is still accurate, unless the feedback was addressed |
| 15:36 | <Domenic> | annevk: I am indeed confused @_@ |
| 15:36 | <Domenic> | what does asFormData() work on, if not application/x-www-form-urlencoded? |
| 15:36 | <Domenic> | I guess multipart/form-data... |
| 15:36 | <Domenic> | Thus option 1) is about making it work on both |
| 15:37 | <Domenic> | whereas asURLSearchParams(), if it were to exist, would work only on application/x-www-form-urlencoded |
| 15:37 | <annevk> | Yes, multipart as FormData handles files |
| 15:38 | <Domenic> | OK. I think I finally understand the OP now. So option 1) is having only asFormData(), but having it work on both of those two formats |
| 15:54 | <annevk> | Domenic: stuffing .loaded and .total on some stream concept actually makes a lot of sense |
| 15:54 | <annevk> | Domenic: going to prototype that in English |
| 15:54 | <Domenic> | For very few streams do you know the size ahead of time |
| 15:55 | <Domenic> | And .loaded doesn't make much sense without the ability to know when it changes, at which point you're probably just consuming the stream anyway. |
| 15:56 | <annevk> | Observing I guess |
| 15:56 | <annevk> | Anyway, for fetch streams you know it surprisingly often |
| 15:56 | <Domenic> | Yeah, passive observation is one thing |
| 15:57 | <Domenic> | not sure you need a .contentLength to alias .headers.get('contentLength') though |
| 15:58 | <annevk> | get('content-length') |
| 15:59 | <Domenic> | right |
| 16:00 | <annevk> | Yeah I guess might refactor it later or some such |
| 16:54 | <Domenic> | This seems bad http://dev.w3.org/fxtf/geometry/#DOMRectList |
| 16:55 | <Domenic> | annevk ^ |
| 16:56 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26200 |
| 16:56 | <Domenic> | I was just about to email public-fx; guess that wil ldo. |
| 16:57 | <Domenic> | Will comment on blink-dev |
| 16:57 | <Domenic> | I wonder if I should switch to using my @google.com email... |
| 17:01 | <annevk> | Domenic: if you plan on never leaving Google |
| 17:03 | <Domenic> | yeah :-/ |
| 17:03 | <Domenic> | Still need to switch to d⊙dm, but that's going to be so much work. |
| 17:06 | <Domenic> | annevk "FYI all these interfaces landed in Firefox and are available in the nightly builds" |
| 17:06 | <Domenic> | how did we let these slip by... |
| 17:09 | <annevk> | Domenic: happened March 18 |
| 17:09 | <caitp> | most of the people I work with are only using their corporate accounts for accessing internal stuff, maybe you don't need it for public mailing lists? |
| 17:09 | <annevk> | Domenic: I think I didn't pay attention because I thought it was already discussed earlier on |
| 17:09 | <Domenic> | Can you pick up the torch to nuke DOMRectList in Firefox? |
| 17:10 | <annevk> | Domenic: as for changing emails, I found it surprisingly easy, just make sure you get both in the same inbox while transitioning |
| 17:10 | <annevk> | Domenic: I don't even know what DOMRectList is for |
| 17:10 | <annevk> | Domenic: if it's getClientRects() it might be needed |
| 17:11 | <Domenic> | ah. |
| 17:11 | <Domenic> | trying to download FF nightly to find out |
| 17:12 | <Domenic> | you can't run nightly and stable at the same time?? O_O |
| 17:13 | <annevk> | Just run Nightly all the time :-) |
| 17:13 | <annevk> | I think the only stable browser I have is Safari because it came with the OS... |
| 17:15 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26103 |
| 17:15 | <annevk> | Domenic: that's effectively your request |
| 17:15 | <Domenic> | Ah yeah it's getClientRects(), sucky |
| 17:15 | <annevk> | Domenic: I don't think I'm getting the idea through to Hixie |
| 17:15 | <annevk> | That specification should call that out somehow, that it's legacy |
| 17:15 | <Domenic> | would be best to name it LegacyGetClientRectsReturnValueType |
| 17:16 | <Domenic> | and make it [NoInterfaceObject] |
| 17:16 | <Domenic> | yeah I should probably chime in on that bug |
| 17:16 | <annevk> | And add Symbol.iterator |
| 17:16 | <annevk> | Symbol.iterator all the things |
| 17:17 | <Domenic> | hmm Chrome has ClientRectList, also exposed globally |
| 17:18 | <annevk> | That was the old name |
| 17:19 | <annevk> | It seems the CSS WG obsession to split all the specs has happened here |
| 17:20 | <annevk> | Oh man, once I'm done with this change in Fetch I've fixed several SUPER HARD BUGS |
| 17:24 | <annevk> | krit: a getter does not an array make |
| 17:26 | <krit> | annevk: beside that it is not of type Array and has not the usual methods of Array it does exactly what authors need to do with it |
| 17:27 | <krit> | annevk: DOMRectList is definitely not intended to be modified |
| 17:27 | <krit> | annevk: at least not by the user |
| 17:27 | <krit> | annevk: you can modify the elements of it though |
| 17:27 | <annevk> | No, you can't map, reduce, etc. |
| 17:27 | <annevk> | And DOMRectList is a snapshot, so it doesn't matter if it's modified |
| 17:30 | <krit> | annevk: who says that it is a snapshot? |
| 17:31 | <annevk> | krit: the spec could be clearer, but I sure hope that it's not live |
| 17:31 | <annevk> | (if it is, the spec needs to be clearer) |
| 17:32 | <annevk> | (can't just return an empty list in that case) |
| 17:32 | <krit> | annevk: it doesn’t because it does not specify the use case |
| 17:32 | <annevk> | ? |
| 17:34 | <krit> | annevk: it is up to the interface thats uses DOMRectList to define if the user can update the elements and it will do something in the backend or if it returns a snapshot |
| 17:35 | <annevk> | 1) DOMRectList should never be used again |
| 17:35 | <Domenic> | That is not how JavaScript works... |
| 17:36 | <annevk> | 2) The usage it has suggests it's only used as static and therefore we might be able to get rid of it |
| 17:45 | <SamB__> | Domenic: what's not how JavaScript works? "it is up to the interface [...]"? |
| 17:50 | <Domenic> | Yes |
| 18:19 | <caitp> | what's going on with the traceur repl arv_ =( seems to be broken today |
| 18:19 | <arv_> | caitp: Let me take a look |
| 18:24 | <arv_> | caitp: Fixed |
| 18:33 | <caitp> | thanks |
| 19:37 | <TabAtkins> | roc: Looks like the formula is that the width calculation yields 0x0 intrinsic size (because there's no src there), then you use 'left' and that width to position it, ignoring 'right' due to overconstraint? (And same with top/height.) |
| 20:09 | <annevk> | TabAtkins: so how do I know email to www-style is tracked? |
| 20:09 | <TabAtkins> | Editor deals with it? (We are bad at giving tracking feedback.) |
| 20:16 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26134 :-) |
| 20:17 | annevk | is not feeling it |
| 20:17 | <annevk> | TabAtkins: that requires tracking on my part |
| 20:25 | <montecfel> | Is it intended behavior for custom .woff fonts in CSS/Canvas to be drawn with the coordinate system being in the bottom-left rather than top-left? |
| 20:25 | <TabAtkins> | montecfel: Example? |
| 20:25 | <TabAtkins> | I mean, do other font types draw differently somehow? |
| 20:29 | <montecfel> | TabAtkins: Well, I don't know. I just know that the one I have does. |
| 20:30 | <montecfel> | And it happens to be a .woff. |
| 20:30 | <montecfel> | And AFAIK, .woff is the only format to use these days. |
| 20:30 | <montecfel> | It seems like they normally are counted with a top-left coordinate system. |
| 20:30 | <TabAtkins> | montecfel: Okay, your questions was misleadingly detailed. ^_^ |
| 20:30 | <SamB> | montecfel: I believe fonts normally orient their axes in this manner, yes |
| 20:31 | <TabAtkins> | I think text drawing is usually done by specifying the point that the baseline begins at. What do you mean by "in CSS"? |
| 20:31 | <TabAtkins> | I know SVG <text> anchors things bottom-left, and I think canvas text does too. |
| 20:31 | <SamB> | if you're talking about coordinates included in the font |
| 20:32 | <SamB> | where "bottom left" doesn't mean bottom left of the bounding box, of course, but merely the reference point, which is at the left of the boundingbox and on the baseline |
| 20:32 | <Philip`> | montecfel: You can change ctx.textBaseline for canvas text - the default baseline is at the bottom of the letters |
| 20:34 | <montecfel> | Hmm... |
| 20:34 | <montecfel> | Well, I "load in" the .woff in a .css. |
| 20:34 | <montecfel> | But then I use it to draw inside a Canvas. |
| 20:35 | <TabAtkins> | Okay, and when you tell it to draw at, say, (10, 20), it puts the bottom-left of the text string at 10,20, and you're confused by that? |
| 20:35 | <SamB> | montecfel: sounds like you might want to look into .textBaseline |
| 20:35 | <SamB> | Philip`: that is a very unusual default |
| 20:35 | <TabAtkins> | SamB: ? Why is it unusual? |
| 20:36 | <TabAtkins> | That's the standard english baseline, shared by most writing systems. |
| 20:36 | <SamB> | well, what if I had, say, a j |
| 20:36 | <SamB> | oh, he was speaking loosely? |
| 20:36 | <TabAtkins> | He didn't mean "literally bottom". |
| 20:36 | <SamB> | ah |
| 20:36 | <SamB> | cool |
| 20:36 | <SamB> | I was worried for a moment |
| 20:36 | <SamB> | TabAtkins: sorry, I think I left my sanity at the door or something |
| 20:36 | <TabAtkins> | Heh. |
| 20:41 | <TabAtkins> | montecfel: Still there, or did things solve themselves? |
| 20:49 | <montecfel> | Problems never solve themselves for me. |
| 20:50 | <montecfel> | Back, though. |
| 20:50 | <montecfel> | Hmm. That sounds like a property/directive that might come in handy indeed. |
| 20:50 | <TabAtkins> | Okay, so looking at my previous line to you, is that the part where you're confused? |
| 20:50 | <TabAtkins> | Note that messing with baselines is probably more confusing than you realize. |
| 20:50 | <montecfel> | Well, I believe this is what is happening, yes. |
| 20:50 | <montecfel> | But this will be a thing I have to invest for the next project. |
| 20:51 | <TabAtkins> | Yeah, if you can figure out something that works, go for it. |
| 20:51 | <TabAtkins> | But the behavior you're seeing is very standard for direct text-drawing APIs. You're probably just dealing with confusion from CSS, where you never draw text directly, you position a box that *contains* text. |
| 21:55 | <Domenic> | Hixie: given the brand-color kerfluffle, do you think updating the HTML spec to say something like "if your meta tag changes user agent behavior, it needs to be in this spec" would be a good idea? |
| 22:02 | <jamesr_> | if it changes UA behavior that isn't observable from the web that doesn't sound like a good idea |
| 22:02 | <jamesr_> | it'd be weird for the HTML spec to start making statements about browser UI |
| 22:05 | <Hixie> | Domenic: what kerfuffle? |
| 22:06 | <Domenic> | Hixie: https://groups.google.com/a/chromium.org/d/msg/blink-dev/nzRY-h_-_ig/KR3XWn73tDoJ ? |
| 22:07 | <Hixie> | i wouldn't call that a kerfuffle, but ok |
| 22:07 | <Hixie> | the solution with that kerfuffle is easy |
| 22:07 | <Hixie> | blink should just support the property names the other browsers used |
| 22:07 | <Domenic> | ok. so they should be specced? |
| 22:07 | <Hixie> | all meta values should be specced |
| 22:08 | <Domenic> | do you think the wiki is sufficient then? |
| 22:08 | <Domenic> | it seems to easy to just create a new proprietary meta thing and then say "we specced it on the wiki" without ever actually trying to collaborate across browsers |
| 22:08 | <Hixie> | it's easy to just create a proprietary element and do that too |
| 22:08 | <Hixie> | or to create something in a closed silo ignoring feedback from others |
| 22:09 | <Hixie> | even if it's not proprietary |
| 22:09 | <Hixie> | or to disagree with someone and just shut them out instead of addressing their feedback |
| 22:09 | <Hixie> | there's all kinds of ways that you can do an end-run around community-driven spec development |
| 22:09 | <Hixie> | it's life |
| 22:10 | <Hixie> | changing the spec to say that things have to be in the spec won't change anything |
| 22:10 | <Hixie> | (if it did, we wouldn't have the stupid stuff with ruby extensions, e.g.) |
| 22:10 | <Domenic> | sure. but i would rather people feel bad about creating something proprietary, than feel good about creating something spec-compliant (via the wiki). |
| 22:11 | <Hixie> | people won't feel bad |
| 22:11 | <Domenic> | well, the spec currently says "it must be in the wiki" |
| 22:11 | <Hixie> | yeah, and no vendor until chrome put it in the wiki |
| 22:11 | <Domenic> | and that compelled action |
| 22:11 | <Domenic> | hmm |
| 22:11 | <Hixie> | it compelled action the third time it was implemented |
| 22:11 | <Hixie> | with a third name |
| 22:11 | <Hixie> | that's hardly a success |
| 22:11 | <Hixie> | it's a 100% failure rate |
| 22:11 | <Hixie> | 66% failure to register, 33% failure to reuse an existing term |
| 22:11 | <Domenic> | fair. maybe we can't push our luck. |
| 22:12 | <Hixie> | making the barrier higher certainly won't improve matters |
| 22:32 | <TabAtkins> | Hixie: The problem here is that "the spec only requires us to put it on the wiki" was being used as an *explicit justification* for not talking it over with other browsers. It was total bullshit, of course, but having the spec at least address that would have made the bullshit more obvious, and thus less likely to have been stated embarrasingly in public. |
| 22:33 | <Hixie> | the spec requires more than that for a value to be "ratified" |
| 22:33 | <Hixie> | feel free to just mark the value as "discontinued" |
| 22:33 | <Hixie> | since it has received wide peer review and been found wanting |
| 22:34 | <Hixie> | but in any case, changing how the registry system works is something i'd like to do. it's been pending on feedback from hsivonen for a while. |
| 22:35 | <gsnedders> | …what kind of version name is "L"? |
| 22:35 | <Domenic> | Codename for some dessert that starts with L, I assume |
| 22:37 | <Philip`> | I guess they learned a lesson from using "KLP" as the codename for the previous version, so now they just use a single letter until the marketing people pick the real name |
| 22:37 | <gsnedders> | …what kind of version name is "KLP"? |
| 22:38 | <Hixie> | Key Lime Pie, later KitKat |
| 22:38 | <Philip`> | The abbreviation of Key Lime Pie, from before theyrealised how much everyone loves Kit Kats |
| 22:39 | <Philip`> | s// / |
| 22:39 | <gsnedders> | Guess that makes more sense than XP |
| 22:41 | <TabAtkins> | Our versions are always consecutive letters, given dessert names at release. |
| 22:41 | <TabAtkins> | Dunno why we haven't announced the name yet, though. I dont' even know it. |
| 22:41 | TabAtkins | hopes it's Limoncello, so we'll get some in the microkitchens. |
| 22:41 | <Philip`> | (There are still lots of references "klp" in the Android repositories, which is needlessly confusing if you only know the actual release names) |
| 22:42 | <Philip`> | (Then again, there were three separate Jellybean versions, so needless confusion seems to be a habit) |
| 22:43 | <TabAtkins> | Indeed. |
| 22:45 | <gsnedders> | TabAtkins: I'm now imagining a Limoncello launch party, where, uh, the Limoncello flows freely. That would end badly. |
| 22:59 | jamesr_ | is hoping for Lime Pie |
| 23:44 | <roc> | TabAtkins_: right |
| 23:44 | <TabAtkins_> | roc: kk |
| 23:45 | <roc> | annevk: DOMRectList has existed for a very long time. It started off as an IE invention for getClientRects, and then we standardized it. |
| 23:45 | <roc> | annevk: it is not live, and it's entirely possible we can make getClientRects return sequence<DOMRect>. |