| 00:03 | <wycats> | SimonSapin: maybe you can just have an informational slot for the original? |
| 00:04 | <wycats> | jgraham: I think it's likely as true as many sentences of the form "Browser X has shown that Y is possible" |
| 00:04 | <wycats> | but those sentences are said incorrectly in many cases ;) |
| 00:07 | <wycats> | I believe the original sentence by dherman was of the form "Servo is doing some interesting experiments that seem to be working ok so far. They may be worth looking into" |
| 00:15 | <jgraham> | That formulation of the original seems reasonable. The broader form is less reasonable for servo since it is generally compatible with almost no web content so it's impossible to measure compat losses |
| 00:25 | <wycats> | I don't think that's an accurate assessment re: compat |
| 00:25 | <wycats> | but you may have a very high bar |
| 00:26 | <Domenic> | how can you not have a very high bar after Array.prototype.contains |
| 00:26 | Domenic | cries |
| 00:27 | <Domenic> | (https://bugzilla.mozilla.org/show_bug.cgi?id=1075059 for those following along at home) |
| 00:29 | <terinjokes> | what features are looking at being secure sites only? |
| 00:29 | <terinjokes> | i know Service Worker is one |
| 00:30 | <Domenic> | terinjokes: annevk is hoping we can move privacy-sensitive ones like geolocation and videocam access into secure only over the next year or so |
| 00:30 | <Domenic> | terinjokes: probably EME |
| 00:30 | <Domenic> | terinjokes: in Chrome, WebCrypto, since our security guys say it is bad to give the impression of a site using crypto when in reality they could be MitMed. But Firefox disagrees and is shipping it everywhere. |
| 00:31 | <terinjokes> | interesting |
| 00:33 | <Domenic> | also in general http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features |
| 00:33 | <smaug____> | speech API should be probably secure only |
| 00:34 | <terinjokes> | ah thanks, I saw that at Edge, but didn't have a link for it |
| 00:34 | <Domenic> | i wonder if requestAutocomplete is restricted... |
| 00:50 | <terinjokes> | for some reason i thought es6 modules, but looks like I'm wrong |
| 07:21 | <MikeSmith> | about fetch/CORS behavior, is the server supposed to send the Access-Control-Allow-Origin for a 304? |
| 07:42 | <annevk> | Domenic: it is |
| 07:43 | <annevk> | Domenic: https://wiki.whatwg.org/wiki/TLS tracks what I could find |
| 07:44 | <annevk> | terinjokes: ^ |
| 07:45 | <annevk> | MikeSmith: yeah, why not? |
| 09:05 | <zcorpan> | i guess it's too late to make webrtc https only |
| 09:08 | <Ms2ger> | I dunno, is it? |
| 09:12 | <jgraham> | Depends if anyone is using in production on non https, doesn't it? |
| 09:13 | <annevk> | And how long that will last if we deprecate it, but I thought P2P stuff was already TLS-restricted |
| 09:23 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3223 - getUserMedia seems to be allowed on insecure in gecko/blink/presto at least (but it's prefixed in gecko/blink) |
| 09:27 | <annevk> | zcorpan: oh, getUserMedia(), yes, there's a thread about that on public-media-capture that I still need to reply to |
| 09:58 | <MikeSmith> | annevk: for http://people.w3.org/mike/tests/fetch/ an Access-Control-Allow-Origin is sent wwith 200 responses as expected but not for 304 responses |
| 09:59 | <annevk> | MikeSmith: so you won't get to read the 304 response |
| 10:00 | <MikeSmith> | oh? |
| 10:02 | <MikeSmith> | annevk: ah because the browser just revalidates the cache entry? |
| 10:03 | <annevk> | MikeSmith: so this might actually be wrong in Fetch I guess |
| 10:04 | <annevk> | MikeSmith: currently we do a CORS check before we handle response statuses |
| 10:05 | <annevk> | MikeSmith: but even for redirects we require CORS checks to be done |
| 10:05 | <annevk> | MikeSmith: and this is effectively a redirect, so... |
| 10:06 | <MikeSmith> | ok |
| 10:07 | <annevk> | MikeSmith: are you encountering an issue? |
| 10:11 | <MikeSmith> | annevk: I had been thinking it was a bug because of seeing "XMLHttpRequest cannot load ... No 'Access-Control-Allow-Origin' header is present on the requested resource." when testing |
| 10:11 | <MikeSmith> | but now I realize maybe it was just because I was getting a stale cached copy from prior to when the .htaccess file was changed to add the header |
| 10:35 | <annevk> | jungkees: I'm not sure if it's worth repeating, but what you should focus on is the model |
| 10:35 | <annevk> | jungkees: what objects are in play, what is their lifetime, what objects are they associated with |
| 10:35 | <annevk> | jungkees: and then define that model in detail |
| 10:36 | <annevk> | jungkees: and then when you define something like the installing attribute, it will simply return one of the objects in that model |
| 10:37 | <annevk> | jungkees: the way you are writing the service worker specification now will not get you to the finish line |
| 10:37 | <alystair> | Anyone here happen to have a coupon code for the W3C validator suite? registering now >_> |
| 10:40 | <annevk> | I suspect MikeSmith does, but he's prolly not allowed to share those :-) |
| 10:41 | <jungkees> | annevk: Thanks for the comment. I'll soon have time to revisit that point. |
| 10:42 | <annevk> | jungkees: no rush btw, please do enjoy your time off or whatever it is you're doing now :-) |
| 10:42 | <alystair> | is there a room similar to #whatwg but for CSS spec? |
| 10:42 | <annevk> | jungkees: if you need help let me know |
| 10:42 | <annevk> | alystair: irc.w3.org has #css |
| 10:42 | <alystair> | I need to know who to blame for inner box-shadow rendering on <img> |
| 10:42 | <jungkees> | annevk: definitely. I need your help over time :-) |
| 10:43 | <alystair> | (or lack of it) |
| 10:43 | <alystair> | thanks |
| 10:44 | <MikeSmith> | alystair: I Just use the free validator, and for batch validation, the jar from https://github.com/validator/validator.github.io/releases/latest |
| 10:46 | <jgraham> | Woah, the W3C moved into validator sales? |
| 10:48 | <alystair> | perhaps W3C mug sales were not as brisk as they'd hoped? ;) |
| 10:48 | <jgraham> | Oh does that explain why the W3C is still full of mugs? |
| 10:48 | <annevk> | jgraham: apparently getting paid by members was not enough |
| 10:48 | <jgraham> | (sorry ;) |
| 10:48 | <alystair> | too much coffee not enough tea~ |
| 10:49 | <annevk> | I use my W3C mug regularly for tea |
| 10:49 | <annevk> | I got mine from Amy though |
| 10:49 | <alystair> | (I didn't actually know they had mugs, more humorous than I expected) |
| 10:50 | <annevk> | Now I kind of want a WHATWG mug |
| 10:50 | <annevk> | Has anyone figured out how WHATWG green translates to print? |
| 10:51 | <jgraham> | I imagine it looks just as bad as on screen :) |
| 10:51 | <darobin> | probably just about as ugly? |
| 10:51 | <jgraham> | heh |
| 10:52 | <alystair> | "ugly mug" would have a much more literal meaning :D |
| 10:52 | <annevk> | We made a t-shirt once, that almost nobody understands. I think I still have mine somewhere and I see hober wearing it sometimes |
| 10:52 | <jgraham> | (back on the subject of the validator suite, those "testimonials" look like filler content) |
| 10:52 | <zcorpan> | createMathMLDocument() huh. http://www.w3.org/TR/MathML2/appendixd.html |
| 10:53 | <MikeSmith> | jgraham: hey I spent a lot of time writing those testimonials |
| 10:53 | <annevk> | It looks they're still for sale: http://five-gt-two.spreadshirt.com/ |
| 10:56 | <annevk> | We even have wallpapers: http://whatwg.majda.cz/wallpapers/ |
| 10:58 | <jgraham> | I was hoping for the kind of wallpaper you can use to decorate your home |
| 11:10 | <annevk> | heh |
| 11:51 | <annevk> | I looked into the style sheet for specifications other than HTML. It seems that for wider screens we could float the table of contents to the right. Perhaps put a border around it or some such or some a wide enough margin. |
| 11:52 | <annevk> | We could also remove the gap on the left. HTML uses that for infoboxes but no other spec has infoboxes at this point and unless Hixie generalizes the API I don't see that happening. |
| 11:52 | <annevk> | zcorpan does place the "select text to file a bug" widget in that left margin, but I'm sure we can think of something. |
| 11:53 | <annevk> | Removing the wide left margin would also allow us to fit more text on the screen for mobile devices. Apparently people do read specs on their phones. |
| 11:59 | <annevk> | Oh, back in '96 W3C used the MIT license: http://www.w3.org/TR/REC-png-961001#Credits |
| 12:00 | <annevk> | Of course, even that was a regression from: http://www.w3.org/Policy.html |
| 12:06 | <Domenic> | wow 5 > 2 that is kind of subtle these days |
| 12:06 | <zcorpan> | i think i don't have mine anymore |
| 12:07 | <darobin> | Domenic: yeah, it comes off almost ironic now |
| 12:07 | <darobin> | I guess today it comes down to a battle between 5 > null and 5 > undefined ;) |
| 12:07 | <Domenic> | heh yeah |
| 12:11 | <Domenic> | broken link at the bottom of https://whatwg.org/specs/. /cc Hixie I guess |
| 12:16 | <MikeSmith> | jgraham: oh man those testimonials really are about completely unispiring as they could be |
| 12:16 | <MikeSmith> | jgraham: I think it just needs pictures, like at http://www.theonion.com/articles/new-antifacebook-social-network-ello-boasts-lack-o,37035/ |
| 12:17 | <MikeSmith> | jgraham: hey, could even borrow even do a variation on the “No advertising is nice, but what really appeals to me is the lack of users.” quote there. Good fit |
| 12:20 | <annevk> | So, when you iterate over FormData you get an Array that consists of DOMString and a File? Does that seem appropriate, Domenic? |
| 12:20 | <zcorpan> | what testimonials? |
| 12:21 | <Domenic> | annevk: not an array, an iterator. but yes. |
| 12:21 | <annevk> | Domenic: well each iterator value would be an array due to lack of tuples, no? |
| 12:21 | <MikeSmith> | zcorpan: middle of https://validator-suite.w3.org/ |
| 12:21 | <Domenic> | annevk: ah right i misread |
| 12:22 | <annevk> | For URLSearchParams, it would be DOMString, DOMString; Headers would be ByteString, ByteString |
| 12:22 | MikeSmith | peruses https://github.com/whatwg/loader |
| 12:25 | <Domenic> | annevk: agree |
| 12:25 | <Domenic> | annevk: that is the default iterator; you also want keys() and values() iterators |
| 12:28 | <zcorpan> | MikeSmith: LOOOOOOOOOOOOOOOOOOL |
| 12:30 | <annevk> | "enhanced validity" |
| 12:30 | <annevk> | Too bad Extended Validation is already a thing |
| 12:31 | <MikeSmith> | oh man I guess I'd be better off having not tried to actually read that page |
| 12:31 | <jgraham> | annevk: "enhanced validity" is going to be the tagline for W3C's new unsolicited email marketing campaign |
| 12:32 | <MikeSmith> | jgraham: that was considered but I think the consensus decision was to go with "now with turbo boost" |
| 12:34 | <MikeSmith> | annevk: trying to figure out how to fit "Reasonably unfiltered" into the messaging there |
| 12:34 | <jgraham> | "can't perform in your text editor? Women laugh at your markup? Get enhanced validity now" |
| 12:34 | <MikeSmith> | hahah |
| 12:36 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183#c17 |
| 12:36 | <annevk> | jgraham: that's a bit sexist |
| 12:38 | <jgraham> | annevk: I was thinking of viagra spam, which is generally marketed at men |
| 12:43 | <Domenic> | annevk: seems similar to the MapLikeIterator from that other bug |
| 12:43 | <Domenic> | annevk: which was blocked on figuring out what the abstract model should be |
| 12:43 | <Domenic> | annevk: "blocked" = "I was too lazy to propose that part because it is harder" |
| 12:48 | <annevk> | Domenic: perhaps at this point IDL should just expose the hooks for iterators as I suggested in the end and we can define the templates ourselves |
| 12:48 | <annevk> | Domenic: templates for multimap-like, set-like, etc. |
| 12:48 | <annevk> | Domenic: and then much later uplift the whole thing to something better |
| 12:50 | <Domenic> | seems reasonable I guess |
| 13:09 | <beverloo> | annevk, what exception for incorrect invocation? |
| 13:09 | <beverloo> | we have no exceptions on that code path (N.requestPermission) |
| 13:09 | <annevk> | beverloo: e.g. Notification.requestPermission("TEST") throws I think |
| 13:09 | <annevk> | beverloo: you haven't studied the full code path then ;-) |
| 13:10 | <beverloo> | ah, binding magic |
| 13:23 | <jgraham> | Isn't the conversation that's currently playing out on whatwg@ exactly what Hixie complained about with the use of rejection for exceptional conditions? |
| 13:34 | <annevk> | jgraham: don't think so |
| 13:35 | <jgraham> | annevk: OK, well I mailed the list so feel free to explain why I'm wrong |
| 13:37 | <annevk> | maybe later |
| 13:41 | <jgraham> | Now I feel rejected :p |
| 13:50 | <Domenic> | annevk: FWIW I feel like it comes down to names, and "request" is ambiguous |
| 13:50 | <Domenic> | If it it was "getPermissionFromUser()" then I would say not getting permission is exceptional |
| 13:50 | <Domenic> | if it was "doesUserAllowCameraAccess()" then it would be clearly unexceptional |
| 13:51 | <Domenic> | but "requestPermission()" could go either way |
| 14:13 | <Domenic> | link to the bug on speccing animation frame tasks and tying CSS animations into all that? |
| 14:30 | <gsnedders> | jgraham, hsivonen: my gut says that the fragment parsing tests should probably be in a separate test file; thoughts? |
| 14:57 | <annevk> | Domenic: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26839 is the latest on animation frame tasks |
| 14:58 | <annevk> | Domenic: if you ignore the name, since whether we call it requestMoon() or getMoon() seems hardly relevant, what behavior do we want? What code do we want people to write? |
| 14:58 | <annevk> | jgraham: hah, just deferred |
| 15:24 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/412 ping |
| 15:29 | <slightlyoff> | looking |
| 15:30 | <slightlyoff> | JakeA is out (vacation) IIRC |
| 15:31 | <annevk> | slightlyoff: you're more than acceptable as stand-in :p |
| 15:41 | <annevk> | TabAtkins: I feel like you should talk to Domenic about how to sort that mismatch |
| 15:41 | <annevk> | TabAtkins: I agree with you that it makes a lot of sense to group all "failure", but then the async/await path really sucks |
| 15:59 | <slightlyoff> | I think that the described behaiour is fine, annevk |
| 15:59 | <annevk> | slightlyoff: and the new name? |
| 15:59 | <slightlyoff> | annevk: is the name change related to the value of Cache-Control? or of the option to fetch? |
| 15:59 | <annevk> | slightlyoff: fetch |
| 15:59 | <annevk> | cache-control is not really affected in any way I hope |
| 15:59 | <slightlyoff> | I'd like it to not have a dash = ) |
| 16:00 | <slightlyoff> | but otherwise I don't mind |
| 16:00 | <slightlyoff> | it seems fine. Defer to Horo-san on actual behavior, but this seems fine WRT our impl |
| 16:14 | <Ms2ger> | https://twitter.com/CDN_Antitheist/status/517252789680877568 |
| 16:15 | <annevk> | Ms2ger: those replies lol |
| 16:29 | <TabAtkins> | annevk: I agree that it sucks. |
| 16:30 | <TabAtkins> | annevk: Though we could always add a Promise.prototype method that shifts *some* rejects into fulfills, when they're tagged as "not fatal" or something. |
| 16:30 | <TabAtkins> | await geo.request().lessThrowing() |
| 16:31 | <TabAtkins> | Or something else like that, I dunno. |
| 16:31 | <annevk> | I guess Domenic's point is that it should be the other way around |
| 16:31 | <TabAtkins> | Maybe a different keyword, one that only rethrows "fatal" rejects, and one that throws all of them. |
| 16:32 | <TabAtkins> | annevk: Yeah, but his "other way around" is optimized for `await`, not promises. We can fix one of them, the other's frozen. |
| 16:38 | <annevk> | I'm rather aligned personally with the return/throw analogy. |
| 16:38 | <annevk> | (And to be clear, a network error seems like something you'd throw for since that is exceptional. Normally that works.) |
| 16:41 | <jgraham> | Hmm, depends what you mean by "network error" |
| 16:41 | <jgraham> | I'm familiar with APIs that throw for socket errors, but less so with ones that would throw for e.g. a 500 HTTP response |
| 16:42 | <annevk> | jgraham: network error is defined in https://fetch.spec.whatwg.org/ |
| 16:42 | <TabAtkins> | annevk: I thought that fetch() fulfilled for failure responses. |
| 16:42 | <annevk> | TabAtkins: failure being? |
| 16:43 | <TabAtkins> | Hm, from a quick reading of the definition of "network error" in the spec, I'm not sure. It doesn't go into any detail about what sorts of things cause network errors. |
| 16:44 | <annevk> | Yeah, you need to read through the spec |
| 16:44 | <TabAtkins> | UGH WHY IS IT SO HARD |
| 16:44 | <annevk> | But typical scenarios include the network failing, CORS failing, infinite redirects |
| 16:44 | <annevk> | HTTP 500 is not a network error |
| 16:45 | <annevk> | The network is fine, it's the server that's not |
| 16:45 | <TabAtkins> | Ah, kk |
| 16:45 | <jgraham> | Really? https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 sounds like it is, but I might be missing something |
| 16:47 | <annevk> | jgraham: that would be CORS failing |
| 16:48 | <annevk> | jgraham: CORS is a protocol layered on top, but any failures have to be masked as network failures for security |
| 16:48 | <jgraham> | Oh I see |
| 18:47 | <Hixie> | so i'm working on replacing the in-spec feature boxes with just importing the caniuse data |
| 18:47 | <Hixie> | anyone have any opinions on this? |
| 18:47 | <Hixie> | e.g. should I just look at the state of the latest version? |
| 18:47 | <Hixie> | most widely used version? |
| 18:47 | <Hixie> | any version? |
| 18:47 | <Hixie> | (version of a browser, i mean) |
| 18:47 | <Hixie> | i'm leaning towards "latest" |
| 18:48 | <Ms2ger> | Latest |
| 18:48 | <Hixie> | k |
| 18:49 | <Hixie> | i'm thinking that i should get the N most popular browsers, probably N=5 since we have 5 icons right now in the box, and then i just show the icons of the the subset of those browsers that support the feature |
| 18:49 | <Hixie> | instead of the current hidden icon / shown icon thing |
| 19:05 | <annevk> | Loving unimpressed marcosc |
| 19:06 | <annevk> | Hixie: while you do that, can you consider a change in styling that makes them floats and uses the sidebar for text rather than mostly whitespace? |
| 19:06 | <annevk> | Hixie: in particular on devices with smaller screens, it feels a bit like a waste |
| 19:07 | <annevk> | Hixie: I might fork the style sheet (or override) for a while to do something else on other specs |
| 19:07 | <Hixie> | how do you mean? |
| 19:07 | <Hixie> | the margin's roughly the same on both sides, no? |
| 19:08 | <annevk> | Hixie: I think what you should show is since when the feature is supported on a per browser basis |
| 19:08 | <annevk> | Hixie: no, there's an 8em left margin |
| 19:08 | <annevk> | Hixie: very clear in e.g. https://fetch.spec.whatwg.org/#acknowledgments |
| 19:08 | <annevk> | Hixie: outside of HTML that margin is only used for that black arrow |
| 19:09 | <Hixie> | oh, i see, there's a max-width and i happen to have a monitor wide enough that it gives a margin on both sides |
| 19:10 | <Hixie> | i guess we could move the margin to the right, but that doesn't seem like it'd help much... |
| 19:10 | <Hixie> | floats don't work very well so i'm reluctant to use those |
| 19:10 | <annevk> | no shifting the margin is not good :-) |
| 19:10 | <Hixie> | and floats don't let you pin the box to the top of the screen |
| 19:10 | <annevk> | hmm true |
| 19:11 | <Hixie> | if you want i can point the spec to a style sheet you control so you can play with it and see if you can come up with something that works but is better |
| 19:11 | <annevk> | Hixie: do you care to maintain the style sheet for non-HTML specs as well? perhaps the boxes layout can be opt-in? |
| 19:12 | <Hixie> | imho we should keep all the specs consistent |
| 19:12 | <Hixie> | ideally, we'd have all the specs have this caniuse data |
| 19:12 | <annevk> | Hixie: that sounds great to me, can you write the software more generically this time? :-) |
| 19:12 | <Hixie> | though since i'm baking it in at spec generation time to make the html spec load faster, it's not something you'll get for free |
| 19:12 | <Hixie> | the html spec generator is pretty generic, i think? |
| 19:13 | <annevk> | is that public now? sorry I haven't been paying attention much |
| 19:13 | <annevk> | I'm happy to do work to make this work in other specs, either through a <script> or some pre-processing |
| 19:13 | <Hixie> | what generator do you use these days, anolis? |
| 19:14 | <annevk> | Hixie: you could put shared resources in https://github.com/whatwg/resources.whatwg.org/ and they will end up on https://resources.whatwg.org/ |
| 19:14 | <annevk> | Hixie: there's a commit hook that automates that process |
| 19:14 | <annevk> | Hixie: I still use Anolis, have some hopes of switching to Bikeshed |
| 19:15 | <Hixie> | you could lobby tab to add caniuse logic to bikeshed |
| 19:16 | <annevk> | but yeah, as I mentioned earlier today I'd be interested in having less whitespace on small screens |
| 19:17 | <annevk> | perhaps we can use floats there and not do the top align thing |
| 19:17 | <annevk> | and introduce actual content earlier, perhaps by floating the ToC |
| 19:18 | <Hixie> | how about i point the spec to https://resources.whatwg.org/experiment.css (as an additional style sheet) and you can see if you can come up with something nice that replaces what we have now |
| 19:19 | <annevk> | sounds interesting, let's try it |
| 19:21 | <annevk> | biab |
| 19:26 | <Hixie> | annevk: (done) |
| 20:09 | <zcorpan> | Hixie: latest is sometimes "unknown" on caniuse i think. while current version might be "no". but maybe that is ok |
| 20:10 | <Hixie> | i'll skip past unknowns if i have a previous known value |
| 20:18 | <Hixie> | interesting |
| 20:19 | <Hixie> | according to the caniuse.com data, iOS Safari and Android Chrome both have 6.09% usage share |
| 21:07 | <annevk> | Hixie: zcorpan: I would expect us to list the earliest known browser for a given feature |
| 21:07 | <annevk> | Hixie: zcorpan: e.g. IE7+ or some such for XMLHttpRequest |
| 21:09 | <Hixie> | when you say "list" |
| 21:09 | <Hixie> | how do you envisage this being shown? |
| 21:09 | <Hixie> | i mean i was just imagining showing an icon, like now |
| 21:09 | <Hixie> | just... more accurate |
| 21:10 | <annevk> | Hixie: no text? |
| 21:11 | <annevk> | Hixie: I can imagine that if people see IE / Safari supporting it, they wonder which version it is |
| 21:11 | <Hixie> | i'm more or less open to anything, if you have a concrete suggestion :-) |
| 21:11 | <annevk> | [browsericon][versions |
| 21:11 | <annevk> | ] |
| 21:12 | <annevk> | or some such |
| 21:13 | <annevk> | Support in: [FF]22+ [C/O]30+ [IE]11 [S]7 |
| 21:13 | <Hixie> | like, stacked vertically? |
| 21:14 | <Hixie> | here, the style sheet is in now |
| 21:14 | <Hixie> | make me a mockup :-) |
| 21:17 | <annevk> | Hixie: example of a feature that has this? |
| 21:17 | <annevk> | I picked DOMStringMap, no luck |
| 21:17 | <Hixie> | has what? |
| 21:18 | <annevk> | https://html.spec.whatwg.org/multipage/dom.html#the-id-attribute seems fine |
| 21:18 | <annevk> | Hixie: I just thought that if you're going to use the caniuse data, apart from the browsers that supports it, you might also want to mention from which version they support it, if that information is there |
| 21:19 | <Hixie> | i'm happy to do so if you have a suggestion for what it should look like |
| 21:19 | <Hixie> | i'm writing the code to get that data |
| 21:19 | <Hixie> | i'll put it in the markup |
| 21:19 | <Hixie> | and your style sheet will show it |
| 21:19 | <Hixie> | :-) |
| 21:19 | <Hixie> | (for now, fake it with generated content) |
| 21:22 | <annevk> | http://www.w3.org/community/urispec/participants o_O |
| 21:23 | <annevk> | Oh, the only email so far is the one that got me there: http://lists.w3.org/Archives/Public/public-urispec/2014Oct/0000.html |
| 21:23 | <annevk> | So I guess that means it's a no-op |
| 21:24 | <wilhelm> | Wat. |
| 21:24 | <annevk> | Hixie: can you tell me what you plan on changing markup-wise and what remains the same? |
| 21:24 | <annevk> | Hixie: I can't do it tonight, but will give this a shot tomorrow, should be fun to do some tweaking |
| 21:25 | <Hixie> | annevk: i've no plans yet |
| 21:25 | <Hixie> | annevk: assume it'll be identical until further notice |
| 21:25 | <Hixie> | if you do nothing, it'll be identical cos that way i won't have to touch the style sheet :-) |
| 22:15 | <Hixie> | we are gonna have to clean up this caniuse data |
| 22:15 | <Hixie> | the spec links in particular. even if you ignore that they point to TR/ pages more often than not, some of the frag IDs are not very precise. |
| 22:15 | <Hixie> | also there's not that much data here, all things considered. |
| 22:16 | <Hixie> | what do people think: should we keep the current system, or switch to caniuse.com data when the latter would only annotate 26 places in the spec? |
| 22:23 | <Hixie> | jgraham: you around? |
| 22:29 | <Ms2ger> | Hixie, doesn't sound like it's worth it |
| 22:30 | <Ms2ger> | Hixie, I'd be more interested in test results once we aggregate those |
| 22:30 | <Hixie> | i think i'm going to drop the current boxes and replace it with caniuse data and links to bugs |
| 22:30 | <Hixie> | the current links to bugs thing isn't very up to date, i think |
| 22:31 | <Hixie> | and drop the "section status" stuff |
| 22:31 | <Hixie> | but if there's other stuff that can be added in, like test results, i'm happy to add those |
| 23:24 | <Hixie> | kittens, even with the HTML5 spec i get multiple versions of the w3c spec |
| 23:24 | <Hixie> | not quite as bad as the canvas spec was, but still |
| 23:25 | <Hixie> | just in my caniuse/bugs processing code, i have five lines just to recognise URLs that refer to the w3c html5 spec |
| 23:25 | <Hixie> | (i have five lines for the whatwg spec too, but four of those are redirects now) |
| 23:26 | <Hixie> | oh, found another. w3c html5 specs. |
| 23:26 | <Hixie> | six of them. |
| 23:28 | <Hixie> | 7. |
| 23:40 | <Hixie> | TabAtkins: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25472#c18 disagrees with your argument about how a successful promise should never represent user cancelation |