| 01:55 | <GPHemsley> | Hixie_, et al.: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-mouseevent-event-order |
| 01:55 | <GPHemsley> | (mouse event order is now specified) |
| 01:59 | <GPHemsley> | relevant changesets: |
| 01:59 | <GPHemsley> | https://dvcs.w3.org/hg/dom3events/rev/42b609150da6 |
| 01:59 | <GPHemsley> | https://dvcs.w3.org/hg/dom3events/rev/709178ecd5fb |
| 03:52 | <Hixie_> | GPHemsley: have we given up trying to get them to spec it in actual spec style? |
| 03:53 | <Hixie_> | GPHemsley: as opposed to basically by vague example, which is what that is |
| 04:07 | <zewt> | Hixie_: "Implementations MUST implement an API compatible with one another." all specs solved |
| 07:07 | <Ms2ger> | annevk-cloud, a question... Is it safe to replace if (a) { foo.classList.add("x") } else { foo.classList.remove("x") } with foo.classList.toggle("x", a)? |
| 07:31 | <MikeSmith> | Ms2ger: I'm looking forward to seeing the response you get to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532#c29 |
| 07:32 | <Ms2ger> | Maybe it's safer if I don't read the response :) |
| 07:35 | <MikeSmith> | heh |
| 08:21 | <jgraham> | Yeah, I see Ms2ger is wearing his flame-retardant pants this morning |
| 08:23 | <zcorpan> | logic <http://www.w3.org/mid/CALzNm5qDrPt+_AgPrYfn_c3jjcZN8drkAxE6UF8L0XCbM504xg⊙mgc>; |
| 08:23 | <Ms2ger> | zcorpan, /topic |
| 08:24 | <jgraham> | <doubletake> |
| 08:25 | <Ms2ger> | <x-doubletake> |
| 08:38 | <MikeSmith> | "data-* attributes are not parsed." https://lists.webkit.org/pipermail/webkit-dev/2013-October/025775.html |
| 08:39 | <MikeSmith> | saying src-N doesn't present any new problems because we've already data-* is like the fallacy of saying <picture><source> doesn't present any new problems because we already have <video><source> |
| 08:43 | <MikeSmith> | with that, I'll trot my hobbyhorse back to the stable and take a short j break |
| 08:48 | <zcorpan> | of course blink doesn't match gecko for img.x. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2590 |
| 08:53 | <zcorpan> | hmm. not sure how to get a non-zero value in blink |
| 08:58 | <zcorpan> | oh, it returns 0 if the image isn't rendered when the script runs |
| 09:00 | <Ms2ger> | That seems plausible |
| 09:00 | <zcorpan> | https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLImageElement.cpp&type=cs&l=331 |
| 09:05 | <zcorpan> | http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/HTMLImageElement.cpp#143 |
| 09:07 | <zcorpan> | gecko seems to do a layout first |
| 09:12 | <zcorpan> | Hixie_: can you add a delayed-style to domviewer? |
| 09:30 | <zcorpan> | Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23610 i think it doesn't work that way. expecting screen readers to not use screen media is as bad idea as expecting handheld devices to not use screen media |
| 09:31 | <zcorpan> | 'handheld' and 'tv' media are dead |
| 09:37 | <Ms2ger> | http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0248.html |
| 09:39 | <wilhelm> | zcorpan: Indeed. I only use "@media (min-width: 900px)" and the like today, even without screen specified. Oh, and @media print. |
| 09:40 | <zcorpan> | wilhelm: what *you* use is irrelevant :-) what UAs do is to have two mutually exclusive media, 'screen' and 'print' |
| 09:40 | <annevk> | Ms2ger: does if(x) do ToBoolean(x)? |
| 09:41 | <annevk> | Ms2ger: if so, I suspect them to be identical, yes |
| 09:41 | <Ms2ger> | I assume so |
| 09:41 | <Ms2ger> | annevk, how about a===undefined? |
| 09:42 | <annevk> | Ms2ger: hah |
| 09:43 | <Ms2ger> | annevk, not at all surprising, right? :) |
| 09:50 | <Marcos> | I want to ask this to the room generally, it's more or less a quick question. In terms of spec (or at least, conceptually in some way) is there any reason why, in HTML, the body element's, or the html element's default/minimum size isn't the size of the viewport? I mean, it's easier, from the developer's perspective to make it/content translucent so that it doesn't fill to the viewport if desired than it is to make it such that co |
| 09:50 | <Marcos> | ntent DOES stretch to the viewport, right? |
| 09:50 | <webben> | zcorpan: I think Hixie_ conflates a non-visual browser and a system screen reader in an impractical way. |
| 09:52 | <annevk> | Marcos: other than using some weird table magic and maybe now with flexbox there was no way to describe that before |
| 09:56 | <Marcos> | ... given that the viewport exists (and is otherwise white) whether or not the content fills it, what I'm probably saying is that the root element of a document should BE the viewport. Outside of it being defined by the document author, I see no advantage of the reverse. It's /sort of/ required in order to make pages display on all screens appropriately, (up to infinitely sized should probably be done, given the unpredictability) |
| 09:56 | <Marcos> | I've never seen a website which intentionally didn't take up the viewport with w/e background it had. |
| 09:56 | <jgraham> | Marcos: Surely annevk or Hixie_ has one that does that :) |
| 09:57 | <jgraham> | It's the law of little-known web featurs |
| 09:57 | <jgraham> | *features |
| 09:57 | <Marcos> | I realise that NOW it might be hard to change, whilst maintaining backward compability, this is a hypothetical. |
| 09:57 | <annevk> | Marcos: do you mean viewport or canvas? |
| 09:58 | <Ms2ger> | Or SVG? |
| 09:58 | <Marcos> | Well, that depends on how we define canvas, annek. |
| 09:58 | <annevk> | Marcos: per its CSS definition |
| 09:59 | <annevk> | Ms2ger: :p |
| 09:59 | Ms2ger | should do something useful |
| 09:59 | <Marcos> | That's not something I've seen myself, annevk. I |
| 09:59 | <Marcos> | am not the type to read every word ever written about sotfware that I use. |
| 10:00 | <Ms2ger> | Good |
| 10:00 | <Marcos> | Addmittedly, the issue is that I find the process of drawing the line between what is and isn't superflous exausting. |
| 10:00 | <Ms2ger> | A lot of the words written are nonsense :) |
| 10:00 | <Marcos> | So, you'll have to link me, annek |
| 10:01 | <annevk> | Marcos: if you don't understand the distinction it's kinda hard to go into hypotheticals |
| 10:01 | <Marcos> | It |
| 10:02 | <Marcos> | isn't that I don't understand it, it's that I go into too many hypertheticals when thinking about it, until there's too much to concentrate on. |
| 10:03 | <Marcos> | I generally only look up what I need to do what I'm doing, any further than that requires knowing what I willl do in future definitively. |
| 10:04 | <Marcos> | The point is that I've never seen anything that directed me toward the "css definition" of canvas. |
| 10:05 | <Marcos> | It sounds like it's some 9001 page preamble somewhere. |
| 10:08 | <Marcos> | Which version of CSS defines "canvas" in it's terminology? |
| 10:08 | <Ms2ger> | http://www.w3.org/TR/CSS21/intro.html#canvas |
| 10:10 | <Marcos> | okay, annevk, according to that page, the canvas is infinite, so, neither |
| 10:12 | <Marcos> | I am reffering to the area enclosing any rendered content, to infinite precision |
| 10:13 | <annevk> | Yeah, but what if you have something absolutely positioned with bottom:-5px? |
| 10:13 | <annevk> | In any event, that's not the viewport. You can actually size something to be the viewport these days quite easily. With "height:100vh; width:100vw" |
| 10:14 | <Ms2ger> | Or 1vh/1vw? |
| 10:15 | <Marcos> | "vh", "vw" are these implimented dimensions? |
| 10:15 | <annevk> | Ms2ger: no, for some reason they decided to divide by 100 |
| 10:15 | <Ms2ger> | annevk, I guess that must be 100 times better |
| 10:17 | <Marcos> | And if you have an absolutely positioned bottom:-5px, unless it's inside a container that's been made non-static, it would, display be extending the canvas. |
| 10:17 | <Marcos> | In fact, absolutely positioned objects behave as I would want to body tag to. |
| 10:17 | <Marcos> | >_> |
| 10:18 | <Marcos> | Sort of, |
| 10:19 | <annevk> | I recommend studying CSS a bit more rather than wondering how it could be different ;-) |
| 10:19 | <Marcos> | It's not functionality I can't produce, it's more that it's something a lot of websites overlook. |
| 10:19 | <Marcos> | I produce it perfectly well, that's not the issue. |
| 10:21 | <Marcos> | It's more that I would have thought that wanting to have the main background minimum sized to the viewport would be more common than not, so I'm wondering why the default is the way it is, I was hoping there was a practical reason I'd overlooked. |
| 10:22 | <Marcos> | I may also be too exhausted to convey my thoughts, which happens a lot. |
| 10:30 | <Marcos> | Lets try this: if I have a page, containing only the body, head, etc. The body tag has a blue background, and a single 50x50 div, black background, absolutely positioned, bottom:-5px;. Why would it be assumed that I want this white bar below it? https://dl.dropboxusercontent.com/u/37122446/Capture.PNG |
| 10:30 | <Marcos> | annevk? |
| 10:34 | <annevk> | Marcos: seems like a browser bug |
| 10:34 | <annevk> | Marcos: background on <body> puts it on the canvas (unless you have a background on <html>) so you cannot see white anywhere |
| 10:35 | <Marcos> | Ah, so it IS supposed to do that. |
| 10:36 | <Marcos> | It occurs cross browser though, I could have sworn |
| 10:36 | <annevk> | No it doesn't |
| 10:38 | <Marcos> | hold on, I'll upload something I had from class, |
| 10:40 | <Marcos> | https://dl.dropboxusercontent.com/u/37122446/temp2/w8/airline.xml |
| 10:42 | <Marcos> | background-size:cover; covers only content on the page in ff, chrome and ie |
| 10:42 | <annevk> | Marcos: in XML you need to style the <html> element |
| 10:42 | <Marcos> | As in, put the background on there? |
| 10:42 | <Marcos> | because I've tried that |
| 10:43 | <annevk> | Marcos: oh no it's not that |
| 10:43 | <annevk> | Marcos: you put a gradient there |
| 10:43 | <Marcos> | so? |
| 10:44 | <annevk> | Marcos: gradients are images, and won't stretch over the canvas, because the canvas is infinite |
| 10:44 | <annevk> | Marcos: in any event, for further questions please find someone else or go to stackoverflow.com |
| 10:44 | <annevk> | Marcos: I'm supposed to be writing standards, not help students with their homework |
| 10:46 | <Marcos> | It's not homework, it's a question about the standards, but you've given me a lot of time, and actually brought some light to the issue for me, so thank you. |
| 10:47 | <Marcos> | If the canvas is by default infinite, that does cause problems. |
| 10:48 | <Marcos> | It really doesn't have any bearing on school work or anything, it's just a peeve I have, lol. |
| 10:48 | <Marcos> | Anyway, bye. |
| 11:22 | <zcorpan> | annevk: no, background on body applies to canvas in xhtml also |
| 11:49 | <jgraham> | Hmm, looks like bratell misunderstood the internet. imgur is for cats/"memes" |
| 13:09 | <annevk> | zcorpan: I know |
| 13:13 | <zcorpan> | annevk: ok, the "in XML you need to style the <html> element" comment was what i responded to, i didn't look at the page |
| 13:14 | <annevk> | zcorpan: yeah, I retracted that a statement later |
| 13:14 | <annevk> | I guess I could have been clearer |
| 13:18 | <GPHemsley> | Hixie_: As I recall, there was more support for fixing the W3C spec than starting a new one. I may be wrong. |
| 13:21 | <annevk> | GPHemsley: you cannot really fix something inherently broken though |
| 13:21 | <GPHemsley> | annevk: I though you were the one suggesting it... :/ |
| 13:21 | <GPHemsley> | +t |
| 13:21 | GPHemsley | shrugs |
| 13:22 | <annevk> | GPHemsley: I think my suggestion has always been to write a lot of tests, write down the optimal model supported by those tests and legacy constraints, write the API requirements around that model, write new tests, get implementations fixed, etc. |
| 13:25 | <jgraham> | Yes, fixing events is a lot of work, and no one seems to want to put in the hours |
| 13:25 | <jgraham> | e.g. http://i.imgur.com/039VHDk.png is just for the click event on links |
| 13:26 | <jgraham> | Then you have to work out which of those bewhaviours forms the sanest compatible subset, and specify that |
| 13:27 | <jgraham> | and also get implementors on board with changing their browser in a potentially dark-matter affecting way |
| 13:29 | GPHemsley | wonders who is testing Minefield in 2013. |
| 13:30 | <annevk> | I was. Until I got a new laptop in Feb at which point I downloaded Nightly.app. Before that it was called Minefield.app though otherwise identical. |
| 13:32 | <jgraham> | Right, it can locally be called "Minefield" even though that's not the name any more |
| 13:33 | <jgraham> | The point is that it's the 2013-08-20 nightly build |
| 13:36 | GPHemsley | shrugs again |
| 13:37 | <annevk> | GPHemsley: you should get that looked at |
| 13:37 | GPHemsley | was hoping you were already looking at his shrugs |
| 13:40 | <GPHemsley> | But anyway, the point of my shrugs is that I'm just reporting my observations; I'm not qualified to do much analysis, I don't think. |
| 13:44 | <annevk> | Is there a way to get a raw diff out of GitHub? |
| 13:45 | <MikeSmith> | .diff |
| 13:46 | <MikeSmith> | appended to a commit URL |
| 13:46 | <jgraham> | The great thing about github is the super-intuitive UI |
| 13:46 | <MikeSmith> | yes! |
| 13:46 | <MikeSmith> | like Critic :) |
| 13:47 | <jgraham> | I don't think that's ever a claim anyone made though :) |
| 13:52 | <zcorpan> | does ie11 support img.x ? |
| 13:52 | <zcorpan> | ie11 in browserstack doesn't seem to like live dom viewer |
| 14:11 | <Hixie_> | zcorpan: (re media) agreed about handheld and tv, we should fix that. screen readers are basically an artefact of not having real aural browsers, though. anyway my real point in hat bug was the second part, not he first. |
| 14:12 | <Hixie_> | GPHemsley: for which spec? |
| 14:12 | <GPHemsley> | Hixie_: The DOM3/mouse events |
| 14:12 | <GPHemsley> | but apparently I am misremembering |
| 14:14 | <Hixie_> | GPHemsley: ah, well, depends support from whom |
| 14:14 | <Hixie_> | GPHemsley: :-) |
| 14:14 | <Hixie_> | GPHemsley: only person who matters is the one writing the spec, really |
| 14:22 | <zcorpan> | hmm, blink doesn't have scroll() or scrollY? |
| 14:24 | <zcorpan> | seems like img.x / y is just relative to the ICB always |
| 14:33 | <matjas> | annevk: is there more to “grapheme clusters” than just combining marks? |
| 14:34 | <annevk> | matjas: I don't actually know in detail, but it does seem that you always want to operate on grapheme clusters if you are dealing with text |
| 14:34 | <jgraham> | Depends what you mean "dealing with" |
| 14:34 | <annevk> | matjas: you don't want to lose the diaeresis of that n |
| 14:42 | <Hixie_> | zcorpan: thanks so much for taking that bug |
| 14:43 | <Ms2ger> | ^ |
| 14:43 | <zcorpan> | Hixie_: np |
| 14:46 | <annevk> | matjas: so the answer is no |
| 14:51 | <annevk> | matjas: http://www.unicode.org/reports/tr29/#Regular_Expressions and the next section are somewhat interesting |
| 14:54 | <zcorpan> | there, x/y specified |
| 14:55 | <GPHemsley> | ¨n or ñ ? |
| 15:19 | <annevk> | So we have Response objects. They're cool. But how do we indicate that for most responses Set-Cookie / Set-Cookie2 are not exposed. And for CORS responses anything but a whitelist is exposed? |
| 15:20 | <annevk> | Create some kind of visor concept that is returned instead? |
| 15:21 | <annevk> | With a wormhole option if you're feeling adventurous? |
| 15:26 | <jgraham> | annevk: Your mixed mataphors are not making things clear :) |
| 15:28 | <annevk> | jgraham: basically I need a way where APIs such as XMLHttpRequest do the right thing by default but internal callers such as "basic fetch" can still get access to the full response |
| 15:29 | <annevk> | "basic fetch" will want to see any Location headers, but XMLHttpRequest is not allowed by default for a cross-origin response. |
| 15:30 | <annevk> | I could of course move the logic to XMLHttpRequest, but then we'll hit the same problem with ServiceWorker and fetch(), etc. |
| 15:49 | <annevk> | I guess I should just describe the "visor" semantics and invent a new term, "actual" that when used passes through the "visor". E.g. location is null, but actual location could be something... |
| 16:14 | <annevk> | Wait, custom elements is in LC? |
| 16:14 | <annevk> | With its monkey patching of createElement()... Crazy world. |
| 16:20 | <annevk> | jgraham: so we had "filtered response" and an associated "internal response", right? |
| 16:27 | <Ms2ger> | annevk, ahahaha LC |
| 16:27 | <jgraham> | annevk: Yes |
| 16:32 | <annevk> | Hmm, so no-backref does not work two parents up. Hixie_ would it be too expensive to make that recursive or at least check for two parents? |
| 16:33 | <annevk> | Hixie_: scenario is <div class="note no-backref"> <p> <span title=...> ... </span> |
| 16:35 | <annevk> | Hixie_: another problem is that you do .className != "no-backref" rather than !(...classList.has("no-backref) |
| 16:47 | <gsnedders> | Ms2ger: https://github.com/html5lib/html5lib-tests/pull/21 |
| 16:47 | <gsnedders> | Ms2ger: kthxbai |
| 16:48 | <Ms2ger> | gsnedders, ah, whatever. Squash and land it |
| 16:50 | <MikeSmith> | I formally object |
| 16:50 | <gsnedders> | Too late. |
| 16:50 | <gsnedders> | Suck0rz. |
| 16:52 | <Domenic_> | Really impressed and excited by all the html5lib-tests and web-platform-tests work, btw. A half-year or so ago I was trying to find a good set of tests to run jsdom through and it was a mess. (Apparently the original author had run a PHP script to scrape some w3c site to get the original tests, and those were ... not very thorough.) |
| 16:53 | <Domenic_> | It leads to stuff like https://npmjs.org/package/parse5 which runs the parser tests against itself, which is pretty awesome. |
| 16:55 | <MikeSmith> | Domenic_: what parser does jsdom use? it's together in the same repo? |
| 16:55 | <Domenic_> | MikeSmith: no, it uses https://npmjs.org/package/htmlparser2, which is not very good. I want to switch to parse5. |
| 16:55 | <Domenic_> | Actually I want someone else to submit a pull request to switch us to parse5 :P |
| 16:57 | MikeSmith | is not familiar with either parse5 or htmlparser2 |
| 16:57 | <MikeSmith> | last time I tried any HTML parsing it node was a long time ago |
| 16:57 | <gsnedders> | MikeSmith: https://github.com/html5lib/html5lib-tests/tree/master/validator is useless, I presume? |
| 16:57 | <MikeSmith> | and it was really slow |
| 16:57 | <MikeSmith> | gsnedders: no not completely useless |
| 16:57 | <gsnedders> | Domenic_: html5lib-tests is scarcely new. Almost nothing in it dates from the last couple of years |
| 16:58 | <Domenic_> | gsnedders: hmm did not really realize. i guess i was mostly excited about web-platform-tests then. |
| 16:58 | <annevk> | it wasn't on GitHub before, so out of mind |
| 17:00 | <jgraham> | Yes, web-platform-tests is a nice step forward for testing. But there are still *significant* steps that have to be taken before it fulfils its potential. In particular vendors have to both run and *write* tests for w-p-t as part of their normal CI/QA processes |
| 17:00 | <MikeSmith> | Domenic_: have you tried Aria Stewart's parser? |
| 17:00 | <hober> | https://github.com/aredridel/html5 |
| 17:00 | <MikeSmith> | Domenic_: https://github.com/aredridel/html5 |
| 17:00 | <Domenic_> | MikeSmith: I personally haven't but a lot of jsdom users have, yeah. My understanding is it's compliant but slow. And not sure if it's run the tests against itself? |
| 17:01 | <hober> | MikeSmith: :) |
| 17:01 | <MikeSmith> | hober: jinx |
| 17:01 | <MikeSmith> | Domenic_: last time I tried it, it was slow, yeah |
| 17:01 | <Domenic_> | jgraham: yes agreed. Similar issues for test-262. Apparently only Microsoft writes their tests in test-262 format. |
| 17:01 | <MikeSmith> | hober knows it better than me |
| 17:01 | <gsnedders> | Domenic_: Bigger problem with test262 is only ECMA members can contribute |
| 17:02 | <Domenic_> | gsnedders: well, but Ecma members can copy and paste CC0 licensed code. |
| 17:02 | <gsnedders> | Domenic_: And the format got changed to something stupid :( |
| 17:02 | <Ms2ger> | Which is why wpt also contains js tests |
| 17:02 | <Domenic_> | Decent parts of ES are moving to copy-and-paste CC0 stuff :P. Promises and maybe modules in ES6, and likely some test-262. |
| 17:03 | <gsnedders> | (The original format was one function per test, which is nice because you can just run it n times to check JIT behaviour) |
| 17:04 | <gsnedders> | (Probably breaking if the second run gives a different result to the first, when you assume it is stateful) |
| 17:06 | <gsnedders> | Domenic_: Also having to go via a proxy can be a sufficent obstruction to demotivate releasing stuff. I probably would've pushed to get Opera's stuff released long before I actually did if there was a decent chance of it getting into any worthwhile testsuite, instead of it merely be "well some Ecma member might be willing to spend the time to get it in". |
| 17:07 | <Domenic_> | gsnedders: that's fair. Hopefully there will be some Ecma licensing fights soon to clear things up. |
| 17:10 | <gsnedders> | (In the end I only did after Presto became a zombie, and all the easier testsuites to release had been. Was still just going to be a code dump given test262 still seemed a lofty goal. And then I got distracted by other things.) |
| 17:22 | <dglazkov> | good morning, Whatwg!~ |
| 17:23 | <Hixie_> | annevk: should be on the element with the title="", no? |
| 17:24 | <annevk> | Hixie_: well, there's a bunch of those and they're all part of a note |
| 17:24 | <Hixie_> | ah |
| 17:26 | <Hixie_> | annevk: i added grandparent checks |
| 17:26 | <Hixie_> | and switched to classList |
| 17:26 | <annevk> | coolio |
| 17:26 | <Hixie_> | i don't want to walk the whole tree because that can be expensive |
| 17:26 | <Hixie_> | this runs on startup of the html spec across the entire dom |
| 17:26 | <Hixie_> | takes forever as it is |
| 17:26 | <annevk> | :-) |
| 17:27 | <Hixie_> | (i wish i had a better way to fix that) |
| 17:27 | <Hixie_> | (actually the status boxes are the main problem iirc) |
| 17:28 | <jgraham> | Well the status boxes are useless, so there's an easy fix there |
| 17:28 | <jgraham> | (I agree that in principle they are useful, but in practice they aren't) |
| 17:29 | <Hixie_> | i use the bug numbers all the time |
| 17:29 | <jgraham> | Ah, yeah, fair point |
| 17:29 | <Hixie_> | and i refer people to the status lines quite often |
| 17:29 | <jgraham> | It's the other parts that aren't useful |
| 17:29 | <Hixie_> | people who aren't deeply in the work here |
| 17:29 | <Hixie_> | not on the list, etc |
| 17:29 | <Hixie_> | i wish we had a better solution though |
| 17:31 | <jgraham> | Anything that says that "the a element" is "ready for first implementations" is broken to the point of uselessness |
| 17:31 | <jgraham> | Even the W3C allows you to implement <a> |
| 17:32 | <Hixie_> | heh |
| 17:32 | <Hixie_> | update it :-) |
| 17:32 | <Hixie_> | it was the new spec that was ready for first implementations |
| 17:32 | <Hixie_> | but yeah, i should probably go through and mark things as done |
| 17:32 | <annevk> | I'm loving this filtered response concept. |
| 17:34 | <jgraham> | Hixie_: Well of course we could update everything once, but unless someone actually keeps it up to date, it isn't that useful. And so far we have several years of evidence that no one wants to keep it up to date. |
| 17:35 | <Ms2ger> | We should get test links in there, though |
| 17:37 | <jgraham> | Ms2ger: Yeah, that might even work OK for HTML since the directory structure somewhat supports it |
| 17:45 | <hober> | Domenic_: MikeSmith: it's slow, but correct. i've mostly used it in static markup generation, where it doesn't really matter how fast it is |
| 17:55 | <Hixie_> | jgraham: if we updated it every few years, we'll still be keeping it more up to date than anyone else :-) |
| 17:55 | <Hixie_> | annevk: filtered response? |
| 17:56 | <jgraham> | Hixie_: Well less up to date than caniuse.com, for example. And mcuh less up to date than the relevant timescale of 6 weeks set by the browser cadence |
| 17:56 | <annevk> | for APIs such as XHR I want to hand them something where if they ask for the headers, Set-Cookie and Set-Cookie2 are already out |
| 17:57 | <annevk> | and if it's a CORS thing, only a certain set of headers are in |
| 17:57 | <Hixie_> | jgraham: yeah, we should probably remove the browser icons. |
| 17:57 | <Hixie_> | jgraham: they seem useless |
| 17:57 | <Hixie_> | jgraham: what we really should do is fine some way to propagate caniuse to them |
| 17:58 | <annevk> | and maybe http://www.chromestatus.com/features |
| 17:59 | <Hixie_> | i wonder what's a good way to do it |
| 17:59 | <Hixie_> | maybe we can put some attributes in the spec somehow |
| 17:59 | <Domenic_> | hober: do you know if it passes the test suite? |
| 17:59 | <Hixie_> | that identify the caniuse data or something |
| 18:00 | <Domenic_> | Hixie_: jgraham: yes please kill the browser icons, quite misleading. "Ready for first implementations" on features that already are everywhere confuses me massively. |
| 18:01 | <hober> | Domenic_: not offhand. i also don't know if it's up to date with the latest parser changes |
| 18:02 | <jgraham> | Hixie_: Well in the long term we should link the status icons to the test suite with zero tests or zero passes meaning "no implementation" and grab the test results from browser-provided data |
| 18:03 | <Hixie_> | i'd be good with that too |
| 18:03 | <Hixie_> | do we have anything resembling the infrastructure for that? |
| 18:03 | <jgraham> | No because as of today no one is running the tests |
| 18:04 | <Ms2ger> | That's jgraham's day job ;) |
| 18:05 | <jgraham> | But yes, this is part of the long term goal of what I'm trying to achieve |
| 18:05 | <Hixie_> | i'm basically happy to implement any of these ideas to make the boxes more useful |
| 18:06 | <Hixie_> | any or all |
| 18:06 | <Hixie_> | last i checked, i just didn't have the data |
| 18:06 | <jgraham> | Right, so that is the big problem |
| 18:07 | <jgraham> | But slowly, slowly we are getting to a world where you will have the data |
| 18:07 | <Ms2ger> | I believe "glacial pace" is the term you're looking for |
| 18:07 | <jgraham> | Aren't 90% of all glaciers retreating? |
| 18:08 | <jgraham> | That seems quite pessimistic :) |
| 18:09 | <Domenic_> | that is a pretty cool day job jgraham |
| 18:09 | <annevk> | jgraham: even by your standards? |
| 18:11 | <Ms2ger> | Domenic_, want to help? ;) |
| 18:11 | <jgraham> | Domenic_: To clarify it doesn't actually involve glaciers ;) |
| 18:11 | <jgraham> | But yes, working on public test infrastructure is cool |
| 18:34 | <Domenic_> | Wait what, XForms is still a thing? https://twitter.com/w3c/status/393437288702570496 |
| 18:34 | <Ms2ger> | No |
| 18:35 | Ms2ger | considers going to ask that question |
| 18:36 | <Ms2ger> | Oh, he gave a talk called "Everything is XML, XML is Everywhere (we just couldn't know it)" yesterday |
| 18:38 | <smaug____> | I wouldn't be surprised if some insurance companies still used it |
| 18:39 | <smaug____> | and I think FF+Xforms addon was used in Germany in some hospitals ... for something |
| 20:57 | <Hixie_> | gsnedders: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22818 |
| 20:57 | <Hixie_> | gsnedders: i'm marking it NEEDSINFO. Reopen if you can clarify it. https://www.w3.org/Bugs/Public/show_bug.cgi?id=22818 |
| 21:22 | <gsnedders> | Hixie_: I'll look at it eventually! |
| 21:41 | <Hixie_> | gsnedders: k. you won't get more reminders from me though, because it's off my radar :-) |
| 21:43 | <gsnedders> | Hixie_: It's open in a tab now. It'll get dealt with at some point. :P |
| 21:43 | <Hixie_> | :-) |
