| 09:38 | <krit> | Are there static versions of the WHAWG specs that can be used for referencing? So a version of the spec to a specific commit that can be referenced and viewed in the browser? |
| 09:45 | <zcorpan> | krit: https://github.com/whatwg/html-mirror - you could use rawgithub.com on a specific commit of complete.html. no multipage though afaik |
| 09:47 | <krit> | zcorpan: so no hosted version? |
| 09:47 | <krit> | zcorpan: just the source itself is in a repository |
| 09:48 | <zcorpan> | krit: https://rawgithub.com/whatwg/html-mirror/f0225ebc726f806502bf85905b40be7f9d4e1311/complete.html |
| 09:49 | <krit> | zcorpan: thanks. Is there a similar option for the other specs like URL or Fetch? |
| 09:49 | <zcorpan> | http: instead of https: to get the style sheet to work |
| 09:49 | <zcorpan> | krit: yeah they are in github so the same trick should work for those |
| 09:50 | <zcorpan> | why do you want to point to a specific commit? |
| 09:50 | <krit> | zcorpan: ok, thanks will take a look |
| 09:51 | <krit> | zcorpan: The specification text changes from time to time as do some definitions. For quoting it is desirable to reference s specific version. |
| 09:52 | <krit> | zcorpan: This can get more important if the W3C has an official statement on normative references to WHAT |
| 09:52 | <krit> | WG specs |
| 09:52 | <zcorpan> | i mean in what context do you want to put the reference? |
| 09:53 | <krit> | zcorpan: in a context of another specification that references a WHATWG spec |
| 09:55 | <zcorpan> | krit: ok. i'm not sure that's a good idea. but my experience with discussing this in the past hasn't been productive so i'll leave it at that :-) |
| 10:02 | <jgraham> | I wont: |
| 10:02 | <jgraham> | That isn't a good idea |
| 10:02 | <jgraham> | Please don't do it |
| 10:02 | <jgraham> | It just means that your reference won't match reality |
| 10:02 | <jgraham> | +' |
| 11:20 | <tobie_> | marcosc: there still seems to be some weird issues with specref. Not sure what gives but the latest release crashes when restarting the application. |
| 11:21 | <tobie_> | marcosc: could there possibly be a file encoding issue (https://github.com/tobie/specref/commit/b30cb27) that wasn't rolled back properly? |
| 11:37 | <jgraham> | zcorpan_: So based on some discussion last night in #testing, I have the idea of making most tests in testharness.js not timeout until the overall harness times out. This means that you wouldn't get the pattern of doing setup({timeout:10100}); async_test("foo", {timeout:10000}) |
| 11:37 | <jgraham> | People would just set timeouts for specific tests in cases where the tests are run in sequence |
| 11:38 | <jgraham> | So that the next test doesn't start before the previous one finished |
| 11:38 | <jgraham> | Does that sound at all sensible? |
| 11:39 | <zcorpan_> | so by default, tests don't have a timeout, but get a TIMEOUT result if the harness times out? |
| 11:40 | <zcorpan_> | and you can still set specific timeout for certain tests in ms? |
| 11:40 | <jgraham> | Yes |
| 11:40 | <zcorpan_> | sounds OK |
| 11:41 | <jgraham> | Makes it harder to integreate with automation since you really want the harness to time out if possible, but that's OK, I think |
| 11:41 | <zcorpan_> | s//don't/ ? |
| 11:42 | <jgraham> | No, I mean you can't just kill the whole browser at the timeout because then you will get 0 results if any test timed out |
| 11:43 | <zcorpan_> | oh |
| 11:46 | <zcorpan_> | so can't you report the result for each test when it's ready? |
| 11:47 | <jgraham> | I could do that I guess |
| 11:48 | <jgraham> | YOu still wouldn't get any result at all for the tests that timed out though |
| 11:48 | <zcorpan_> | right. but you can signal that the test exists when it is created, and consider it to be a TIMEOUT if you don't get anything, maybe? |
| 11:49 | <jgraham> | Yeah. It makes the wire protocol pretty verbose though |
| 11:49 | <zcorpan_> | true |
| 11:49 | <jgraham> | It's probably easier just to add a timeout in js |
| 11:50 | <jgraham> | which will cause all the results to be reported |
| 11:51 | <jgraham> | (this is the setup I originally had, but I moved to the simpler system of just having a single timeout that dealt with all harness timed out / browser hung / etc. scenarios) |
| 13:02 | <marcosc> | tobie_: looks like the encoding broke |
| 13:03 | <tobie_> | Thought so. |
| 13:03 | <tobie_> | No idea how to fix that (outside of a forced update). |
| 13:03 | <marcosc> | tobie_: did you merge in Addison's stuff? |
| 13:04 | <tobie_> | I didn't touch anything. |
| 13:04 | <marcosc> | hmm... ok, looking |
| 13:04 | <tobie_> | Seems that your rollback didn't fix everything. |
| 13:05 | <marcosc> | stupid rollback :) |
| 13:05 | <tobie_> | yeah. |
| 13:05 | <tobie_> | Stupid encoding. |
| 13:05 | <marcosc> | heh, strange because Travis said it was all cool |
| 13:06 | <marcosc> | tobie_: I think I didn't roll back far enough |
| 13:06 | <marcosc> | I needed to go one more |
| 13:06 | <tobie_> | It is possible that the test suite doesn't catch these encoding issues. |
| 13:06 | <tobie_> | (if encoding issues are the problem.) |
| 13:17 | <jgraham> | Wait, what? Service Workers? Is this happening in secret again? |
| 13:18 | <annevk> | jgraham: nah |
| 13:18 | <annevk> | jgraham: stuff just got renamed |
| 13:18 | <jgraham> | Where? |
| 13:18 | <annevk> | jgraham: same place, https://github.com/slightlyoff/ServiceWorker/ |
| 13:19 | <annevk> | jgraham: (old URL https://github.com/slightlyoff/NavigationController/ redirects there) |
| 13:19 | <jgraham> | Well that's clearly a different place |
| 13:20 | <annevk> | *shrug* |
| 13:20 | <jgraham> | Would be nice if all this github stuff didn't take whatwg/webapps entirely out of the loop |
| 13:42 | <krit> | annevk: ping |
| 13:48 | <marcosc> | Encoding question ... we have a JSON file on GH and a pull request we got seems to have changed the encoding. To prevent that from happening, would it be a good idea to at a BOM to the file? |
| 13:51 | <marcosc> | See: https://github.com/tobie/specref/commit/b30cb27 |
| 13:52 | <jgraham> | Aren't JSON files utf8 by definition? |
| 13:52 | <jgraham> | Someone might have given you non-utf8 |
| 13:52 | <hasather_> | marcosc: wouldn't the best thing be to just not accept the pull request, and ask the committer to fix it? |
| 13:52 | <jgraham> | But then you don't have a JSON file... |
| 13:52 | <SimonSapin> | marcosc: who know what broken tool is responsible. I don’t think a BOM would help much |
| 13:52 | <jgraham> | Right, just reject the PR |
| 13:52 | <gsnedders> | "JSON text SHALL be encoded in Unicode. The default encoding is UTF-8" |
| 13:53 | <gsnedders> | (What counts as "encoded in Unicode"?) |
| 13:53 | <jgraham> | Oh |
| 13:53 | <jgraham> | Unicode isn't an encoding |
| 13:53 | <marcosc> | hasather_: the problem is that we didn't spot the problem until after |
| 13:53 | <jgraham> | Crockford is an idiot |
| 13:54 | <gsnedders> | (I can encode into Unicode, as an abstract model, and then serialize it as ISO-8859-1?) |
| 13:54 | <jgraham> | News at 11 |
| 13:54 | <marcosc> | heh |
| 13:54 | <SimonSapin> | "JSON may be represented using UTF-8, UTF-16, or UTF-32." |
| 13:54 | <annevk> | krit: yo |
| 13:54 | <zcorpan_> | UTF-32? Why not UTF-9? |
| 13:54 | <krit> | annevk: hi. The URL spec does not handle data URL's yet. Is that intended? |
| 13:55 | <gsnedders> | SimonSapin: That's different to what it says above! |
| 13:55 | <gsnedders> | SimonSapin: Bloody hell. |
| 13:55 | <jgraham> | (isn't the guy that made the PR in the i18n WG?) |
| 13:55 | <marcosc> | SimonSapin: I was thinking that if we get a PR with the missing BOM, at least we could easily spot that |
| 13:55 | <jgraham> | (if you are American and don't understand irony, that is is) |
| 13:55 | <jgraham> | *it |
| 13:55 | <annevk> | zcorpan_: so I learned yesterday that UTF-9 and UTF-18 are not that crazy: http://en.wikipedia.org/wiki/36-bit |
| 13:55 | <jgraham> | (if you are American and do understand irony, good for you) |
| 13:56 | <annevk> | krit: it does |
| 13:56 | <jgraham> | (if you are some other nationality and don't understand irony, sorry I can't help) |
| 13:56 | <hasather_> | marcosc: wasn't it easy enough to spot that something was broken there? :) |
| 13:56 | <marcosc> | hasather: no, not when we got the request |
| 13:56 | <marcosc> | it looked fine :( |
| 13:56 | <SimonSapin> | marcosc: given that some tool is broken enough to do this in the first place, can you rely on it removing the BOM? |
| 13:56 | <krit> | annevk: so data is not a scheme? |
| 13:56 | <krit> | "data" |
| 13:56 | <marcosc> | SimonSapin: yeah you are probably right |
| 13:57 | <SimonSapin> | krit: I have http://simonsapin.github.io/data-urls/ , but it’s more a collection of issues that anything |
| 13:57 | <SimonSapin> | than* |
| 13:57 | <marcosc> | hasather: see here: https://github.com/tobie/specref/pull/44/files |
| 13:57 | <annevk> | krit: it's a scheme, sure |
| 13:57 | <marcosc> | hasather: that's the original PR - as you can see, it all looks good |
| 13:58 | <marcosc> | but once it merged, it all went bad |
| 13:58 | <annevk> | krit: it's not a relative scheme if that's what you mean |
| 13:58 | <krit> | annevk: ah, that explains |
| 13:58 | <krit> | it |
| 13:58 | <krit> | SimonSapin: still a bit red :) |
| 13:59 | <SimonSapin> | krit: as soon as you poke in the corner cases, nobody knows what should really happen. |
| 13:59 | <krit> | SimonSapin: non-deterministic specs! |
| 13:59 | <jgraham> | marcosc: Uh, no the original PR looks broken |
| 14:00 | <jgraham> | https://github.com/addison/specref/commit/b30cb27ef8eb6356a77f96ceb998d6d4b5386d98 |
| 14:00 | <SimonSapin> | krit: just plain boring undefined |
| 14:00 | <marcosc> | jgraham: strange, because what I reviewed was https://github.com/tobie/specref/pull/44/files |
| 14:01 | <jgraham> | marcosc: There seem to be two commits |
| 14:01 | <jgraham> | One that introduces the error and one that reverts it |
| 14:01 | <marcosc> | ah, that's why I didn't see it |
| 14:02 | <jgraham> | Although it is pretty fricking hard to tell because github is a pile of shit |
| 14:02 | <marcosc> | ... coming to a sad realization too :( |
| 14:04 | <jgraham> | Sometimes I think I should start my own company doing something technically interesting just so that I can have a blog, which would then attract a large readership, finally allowing me to post "github considered slightly crappy" in front of a massive audience, whereupon I would disband the whole enterprise and go back to quietly testing the web |
| 14:05 | <SimonSapin> | jgraham: that’s some yak shaving |
| 14:06 | <annevk> | Domenic_: https://gist.github.com/annevk/6609620 |
| 14:07 | <krit> | annevk: just to make sure. if the URL is "#fragment", than the URL does not have a scheme? |
| 14:08 | <Domenic_> | annevk: https://gist.github.com/domenic/0c47ae300608341f3d7f (but that was before the { done, value } idea) |
| 14:08 | <annevk> | krit: it does after you parse it, or it turns into failure if there's no base URL... |
| 14:09 | <krit> | annevk: ah ok. So after parsing you have an absolute path with a scheme "http" or "frp" for example |
| 14:09 | <krit> | ftp |
| 14:09 | <krit> | (just to name two :P was not meant to be exclusive) |
| 14:11 | <annevk> | depends on the base URL |
| 14:12 | <slightlyoff> | jgraham: there's absolutely a plan to bring this all back to webapps |
| 14:12 | <slightlyoff> | jgraham: the goal isn't to sideline the standards process, but to build consensus slowly among people who are heavily invested in the area |
| 14:14 | <Domenic_> | GitHub is *way* more open, from a developers on the ground perspective, than these mailing lists. |
| 14:14 | <Domenic_> | This is #1 piece of feedback from developers when I give talks on extensible web etc. |
| 14:17 | <krit> | annevk: the spec explains that a URL is either a abs or rel URL which can be followed by a fragemnt. rel URL is a URL w/o scheme but must be relative to base URL… base URL is an absolute URL with relative scheme |
| 14:17 | <annevk> | krit: sure, at the writing level |
| 14:17 | <annevk> | krit: at the spec level you only deal with parsed URLs |
| 14:17 | <krit> | annevk: so how do you get to the base URL |
| 14:18 | <krit> | annevk: … from a relative URL |
| 14:18 | <annevk> | krit: you can parse with a null base (although maybe that ought to be about:blank as a base URL always...) |
| 14:18 | <annevk> | krit: not sure I parse that question |
| 14:19 | <krit> | annevk: the term relative URL is explained with the relation to the base URL |
| 14:19 | <krit> | annevk: and it is not clear to me how the base URL looks like for a base URL from resding the first paragraph |
| 14:19 | <krit> | annevk: (I am at section 5) |
| 14:20 | <krit> | annevk: an introducing example how a URL does look like could help as well |
| 14:20 | <annevk> | krit: the base URL is derived from the URL of the resource, or e.g. <base> |
| 14:20 | <krit> | annevk: I took this as reference :P http://en.wikipedia.org/wiki/URI_scheme#Examples |
| 14:21 | <annevk> | yeah, at some point we should include that I suppose |
| 14:21 | <annevk> | once there's some implementations |
| 14:22 | <krit> | annevk: what is a <base>? according to the spec: optionally with a base URL base |
| 14:22 | <krit> | annevk: which doesn't explain it :) |
| 14:22 | <krit> | annevk: as you noticed, I am no expert at all on URL and try to understand it from just reading the spec |
| 14:23 | <annevk> | krit: <base> is an HTML element |
| 14:23 | <krit> | you mean like <img> |
| 14:23 | <annevk> | krit: yes |
| 14:24 | <annevk> | krit: if there's no base URL, parsing "/test.html" will return failure |
| 14:25 | <annevk> | krit: also if the base URL does not have a relative scheme |
| 14:25 | <jgraham> | I don't really see how github is "more open". I could perhaps buy "more familiar". |
| 14:26 | <annevk> | It's not more open if you use private gists, Domenic_ ;) |
| 14:26 | <krit> | annevk: "the base URL is derived from the URL of the resource, or e.g. <base>" so if <img> is from file://test.html, then base URL is derived from file://test.html |
| 14:26 | <annevk> | krit: no, <base> is an element to override the base URL of a resource |
| 14:28 | <krit> | annevk: how does <img src="image.png"> override the base URL if <img> is in the document at file://test.html? |
| 14:28 | <annevk> | krit: <img> doesn't override the base URL |
| 14:29 | <krit> | Ancil: you said <base> does |
| 14:29 | <annevk> | krit: <base> does |
| 14:29 | <krit> | annevk: and <img> is <base> |
| 14:29 | <annevk> | krit: no, <img> is an element, just like <base> is |
| 14:29 | <krit> | annevk: oh you really mean there is a <base> element? |
| 14:29 | <annevk> | krit: dude |
| 14:30 | <SimonSapin> | http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-base-element |
| 14:30 | krit | is obviously confused |
| 14:31 | <zcorpan_> | hmm. data--="" seems borked in the dataset api |
| 14:31 | <Domenic_> | hah nice zcorpan_ |
| 14:32 | <annevk> | zcorpan_: should be dataset["-"] |
| 14:33 | <zcorpan_> | annevk: yeah. but setting "-" throws |
| 14:33 | <annevk> | zcorpan_: no |
| 14:34 | <zcorpan_> | oh, right |
| 14:34 | <krit> | annevk: ok, got the purpose of <base> :P however, this is HTML specific. So say the example does not have a base element… then the document URL of <img> is used for base URL ? |
| 14:34 | <annevk> | krit: yes |
| 14:34 | <annevk> | krit: <base> also affects SVG, just use the correct namespace |
| 14:35 | <krit> | annevk: ok, thanks |
| 14:40 | <zcorpan_> | wonder if svg should allow <base> in its content model |
| 14:43 | <annevk> | zcorpan_: <base> is terrible, let's not encourage it |
| 17:11 | <TabAtkins> | Hixie_: But we don't have type checking, and it's not likely to happen soon, and when it does it will be completely opt-in, so you should stop trying to design things around the assumption of "this is how a type-checked language would do it". |
| 17:13 | <TabAtkins> | JakeA: There's no reason video can't be in an <img>, and I've suggested that very thing in blink-dev. We're waiting for it to be technically *possible* on our end before seriously considering it. (Right now, spinning up videos is unnecessarily expensive. Doing lots of small git-style videos would kill your page at the moment. We're fixing this.) |
| 17:13 | <TabAtkins> | JakeA: But yeah, basically exposing a Vine-like interface for video-in-<img> would be wonderful. |
| 17:14 | <TabAtkins> | autoplaying and muted, with the only control being an unmute button |
| 17:17 | <jgraham> | Wow, we have very different visions of utopia |
| 17:18 | <TabAtkins> | jgraham: Yeah, you hate gifs, while I enjoy tumblr. |
| 17:18 | <TabAtkins> | Presumably it's related to you being crotchety. ^_^ |
| 17:50 | <JakeA> | TabAtkins: Yeah, although I'm not convinced what problems it solves that <video> with autoplay & no controls doesn't |
| 17:55 | <zewt> | seems better to treat gifs in img as a weird backwards-compatibility thing, and instead optimize <video> to be lighter-weight, but as for how practical or annoying that is to actually implement I don't know |
| 17:57 | <zewt> | (rather than having two ways to do the same thing, and making authors have to pick between "features and expensive" or "no features and cheap") |
| 18:00 | <TabAtkins> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2527 In anything but webkit/blink, could someone try click-dragging some text down to try to force the div to scroll, then try it again starting from the input? |
| 18:03 | <zewt> | no scrolling |
| 18:03 | <zewt> | (in FF, IE9) |
| 18:03 | <TabAtkins> | Okay, cool. |
| 18:03 | <TabAtkins> | chrome scrolls if you start the drag from inside the <input>, which seems like a bug. |
| 18:43 | <JakeA> | zewt: agree about the gif thing. Although is there a good reason to support video content as CSS imagery? |
| 18:53 | <annevk> | matjas: yt? |
| 18:57 | <annevk> | matjas: are you saying https://bugs.ecmascript.org/show_bug.cgi?id=1802 is invalid? |
| 19:00 | <SimonSapin> | TabAtkins: no scrolling in Presto either |
| 19:00 | <SimonSapin> | fwiw |
| 19:05 | <bradleymeck> | Getting people to comment on spec is hard. Still having trouble getting implementors/consumers of MutationObservers to make any comments about them good or bad. Most just acknowledgement of their use/implementation or ask if it causes a bug in their code. |
| 19:07 | <annevk> | bradleymeck: reviewing is hard |
| 19:07 | <annevk> | FWIW: http://wiki.ecmascript.org/doku.php?id=strawman:embracing_workers |
| 19:07 | <bradleymeck> | all of the spec is hard. I gain more respect about specification issues the more I try to talk to people |
| 19:08 | <bradleymeck> | [[transfer]] makes me zoo happy |
| 19:08 | <bradleymeck> | soo* |
| 19:08 | <annevk> | it's non-extensible though |
| 19:09 | <annevk> | mostly much needed refactoring |
| 19:09 | <bradleymeck> | its a proposal for now, just talk about it is encouraging :). I actually had a twitter comment about this topic the other day |
| 19:10 | <annevk> | I know it's a proposal, I just wrote it |
| 19:11 | <jamesr__> | gah respec |
| 19:12 | <bradleymeck> | annevk: Then I forgot to thank you. So thanks on that and on my issues :) |
| 19:32 | <TabAtkins> | jamesr__: What about respec? |
| 19:32 | <zewt> | gah |
| 19:32 | <zewt> | i think he was pretty clear on that point |
| 19:58 | <TabAtkins> | zewt: Yeah, I was wondering *why* he was gah'ing. |
| 20:01 | <annevk> | respec messes up IDL and method definitions generally |
| 20:01 | <annevk> | very much old-style, it's configurable, but nobody does that |
| 20:03 | <TabAtkins> | yeah, it's all kinds of weird. |
| 20:03 | <TabAtkins> | happy with what me and plinss have come up with for Bikeshed. |
| 20:04 | <TabAtkins> | A resilient parser (so it won't die as new features are added to IDL) that we just use to decorate <pre class=idl> contents with <dfn>/<a> markup automatically. |
| 20:04 | <zewt> | TabAtkins: because of respec. duh |
| 20:04 | <TabAtkins> | zewt: Thanks. So helpful. ^_^ |
| 20:04 | <zewt> | i'm helping, i'm helping |
| 20:04 | <annevk> | TabAtkins: Anolis-style compatible? |
| 20:04 | <annevk> | TabAtkins: is Bikeshed open source? |
| 20:05 | <TabAtkins> | annevk: I dunno what Anolis-style is, because it's not documented in the current docs. But I do plan on eventually adding an Anolis compat-mode. |
| 20:05 | <TabAtkins> | annevk: Yes, it's in my github: http://github.com/tabatkins/bikeshed |
| 20:06 | <annevk> | interface <dfn>trololol</dfn> { boolean attribute <span title=dom-trololol-member>member</span>; }; |
| 20:06 | <TabAtkins> | Someone actually documenting Anolis' features would be greatly appreciated, and would bring the compat-switch closer. |
| 20:06 | <TabAtkins> | Why mark anything up? Bikeshed just needs plain IDL text, and adds all the markup automatically for you. |
| 20:06 | <TabAtkins> | But it is marked up in that style, yes. |
| 20:06 | <annevk> | I'm just illustrating what we do now :) |
| 20:09 | <TabAtkins> | http://dev.w3.org/csswg/css-font-load-events/#FontFaceSet-interface shows off the current idl stuff. |
| 20:11 | <TabAtkins> | From this source: http://dev.w3.org/csswg/css-font-load-events/Overview.src.html#FontFaceSet-interface |
| 20:20 | <annevk> | Domenic_: fwiw, I recommend a new thread for the alternative Stream proposal |
| 20:20 | <annevk> | Domenic_: current thread seems lost |
| 20:20 | <Domenic_> | annevk: sounds good. plan to do so by end of weekend probably. |
| 20:21 | <TabAtkins> | Yeah, I lost track of what was going on for the Stream stuff a long time ago. A fresh thread with the proposal would be great. |
| 20:28 | <jamesr__> | TabAtkins: FOUC |
| 20:29 | <jamesr__> | it feels like a system designed by someone who doesn't understand the web |
| 20:29 | <jamesr__> | which is awful for something that's supposed to define the web |
| 20:31 | <TabAtkins> | I think it's just "hey, JS is easy to work with, so let's do the spec generation in it". |
| 20:31 | <TabAtkins> | And then it's accidentally really painful and bad. |
| 20:33 | <matjas> | annevk: no, https://bugs.ecmascript.org/show_bug.cgi?id=1802 is valid |
| 20:34 | <matjas> | unless I misunderstood TR31 (which may very well be the case) |
| 20:35 | <annevk> | matjas: did you see my email? |
| 20:35 | <annevk> | matjas: following the dots it seems 2E2F is fine as ID_Start |
| 20:38 | <matjas> | annevk: Pattern_Syntax, though |
| 20:39 | <matjas> | annevk: just replied |
| 20:40 | <annevk> | matjas: okay, so you're wrong in https://code.google.com/p/v8/issues/detail?id=2892 ? |
| 20:42 | <matjas> | annevk: ES5 doesn’t use ID_Start, it just lists the Unicode categories directly, hence the difference |
| 20:42 | <matjas> | see my old blog post if you’re interested |
| 20:43 | <matjas> | ES6 simplifies the whole thing by just deferring to TR31 (more or less) |
| 20:43 | <annevk> | matjas: okay, so the comment you're making there is about ES5, while I filed a bug about ES6 |
| 20:43 | <annevk> | matjas: actually, you filed that bug, that's just confusing |
| 20:44 | <matjas> | i think your comment #2 on that page is incorrect |
| 20:46 | <matjas> | annevk: V8 currently implements ES5 rules for identifiers, so it allows 2E2F |
| 20:47 | <matjas> | but it shouldn't since it won't be allowed anymore in ES6 |
| 20:47 | <annevk> | I see what you mean, however, saying to blacklist 2E2F does not seem appropriate either |
| 20:47 | <annevk> | The list needs to be generated based on ID_Start |
| 20:48 | <matjas> | i see. so in your comment you meant to say "generate the list based on TR31 as per ES6 rather than hardcoding the categories as per ES5" |
| 20:49 | <matjas> | simply using a different Unicode version would not make a difference for 2E2F afaict |
| 20:50 | <annevk> | yes (to both) |
| 20:51 | <matjas> | then we're in agreement |
| 21:18 | <Hixie_> | krit|zZz: i try to discourage referencing old versions, because they tend to end up in google search, and then you end up with the kind of mess the w3c has, where people are always ending up looking at obsolete specs without realising it |
| 21:19 | <Hixie_> | krit|zZz: other specs should _definitely_ never refer to a version of the spec with bugs that have since been fixed |
| 21:22 | <Hixie_> | zcorpan: did you conclude data--="" worked ok with the API, or is there a bug in the spec? |
| 21:22 | <annevk> | Hixie_: works ok |
| 21:22 | <Hixie_> | TabAtkins: i don't design things around the assumption of "this is how a type-checked language would do it". |
| 21:22 | <zcorpan> | Hixie_: i think the spec is ok |
| 21:22 | <Hixie_> | k |
| 23:08 | <Hixie_> | teehee, anne keeps saying "plan of record" |
| 23:09 | Hixie_ | wonders where this record is :-) |
| 23:11 | <jgraham> | Doesn't "plan of record" just mean "what TC39 are thinking this week"? |
| 23:12 | <jgraham> | </rimshot> |
| 23:12 | <Hixie_> | one of them was about javascript: and navigation, which i think is just the fetch spec, not anything to do with js |
| 23:14 | <jgraham> | I wasn't being serious :) |
| 23:20 | <reyre> | how does the positioning in the webvtt processing model with 'vw' and 'vh' CSS units make sense? these will mostly always be relative to the page viewport |
| 23:22 | <Hixie_> | the viewport is redefined for vtt purposes |
| 23:22 | <Hixie_> | or at least, it used to be, i assume that's still there |
| 23:22 | <Hixie_> | search for "viewport" |
| 23:24 | <reyre> | Hixie_: i'm not seeing anything, but i see a lot of references to 'video viewport' so i guess it's implicit |
| 23:24 | <Hixie_> | file a bug to make it explicit :-) |
| 23:24 | <reyre> | but why not just use % |
| 23:24 | <reyre> | it's the same in practice, no? if we just use % |
| 23:24 | <Hixie_> | (but i'm pretty sure it was explicit) |
| 23:24 | <reyre> | Hixie_: i'll take a closer look |
| 23:24 | <Hixie_> | i don't think it's the same, but i don't have it paged in |
| 23:26 | <reyre> | Hixie_: ah "The viewport (and initial containing block) is video's rendering area." |