| 00:00 | <nicholasserra> | Anyone here familiar with the html5lib python library? |
| 00:00 | <TabAtkins> | Kinda. |
| 00:00 | <TabAtkins> | (I use it, but not sure how "familiar" I am with it.) |
| 00:00 | <TabAtkins> | If gsnedders is around, he's one of the authors. |
| 00:01 | <nicholasserra> | Awesome. Just seeing issues with the order of attributes not consistent from one environment to another. |
| 00:01 | <nicholasserra> | When parsing some html |
| 00:02 | <gsnedders> | Yes. We don't really preserve attribute order. |
| 00:02 | <gsnedders> | Most of the tree structures we parse to don't keep order of attributes. lxml currently does, but it explicitly documents that the order is undefined. |
| 00:03 | <nicholasserra> | gsnedders: So is it just random? Problem is that locally I have tests that check for appropriate dom. But then when I push to travis.ci, travis runs those same tests and gets a different order, and fails. |
| 00:03 | <TabAtkins> | You can pass alphabetical_attributes=True to the serializer constructor, though. |
| 00:03 | <nicholasserra> | TabAtkins: I think that would save me |
| 00:03 | <gsnedders> | Right, that's on the serializer side |
| 00:03 | <TabAtkins> | walker = html5lib.treewalkers.getTreeWalker("lxml") |
| 00:03 | <TabAtkins> | s = html5lib.serializer.htmlserializer.HTMLSerializer(alphabetical_attributes=True) |
| 00:03 | <TabAtkins> | rendered = s.render(walker(self.document)) |
| 00:03 | <gsnedders> | TabAtkins: Don't do that. |
| 00:04 | <TabAtkins> | gsnedders: Cool, document how to do it otherwise. ^_^ |
| 00:04 | <zewt> | get.java.out.of.my.python |
| 00:04 | <gsnedders> | TabAtkins: html5lib.serialize(self.document, tree="lxml", alphabetical_attributes=Trues) |
| 00:04 | <gsnedders> | I think |
| 00:04 | <gsnedders> | I don't know, I'm watching Buffy! :P |
| 00:04 | <nicholasserra> | here's how i'm using it |
| 00:04 | <nicholasserra> | https://gist.github.com/nicholasserra/e86a2e1762b11643be37 |
| 00:05 | <TabAtkins> | Yeah, looks like that worked. |
| 00:05 | <nicholasserra> | gsnedders: Can I pass alphabetical to the .render()? |
| 00:05 | <TabAtkins> | nicholasserra: So yeah, just add alphabetical_attributes there. |
| 00:05 | <TabAtkins> | To the HTMLSerializer() call. |
| 00:05 | <TabAtkins> | Or shorten your code as gsnedders shows. |
| 00:06 | <gsnedders> | nicholasserra: nah, it needs to be when creating HTMLSerializer |
| 00:06 | <nicholasserra> | Ah, beautiful. |
| 00:06 | <gsnedders> | But really use the shorter version :) |
| 00:06 | <gsnedders> | TabAtkins: And that isn't documented anywhere? Oh. :) |
| 00:06 | <TabAtkins> | gsnedders: Who knows, it might be. But I certainly didn't find it when I dug around to figure out how to do what I was doing. |
| 00:07 | <TabAtkins> | And apparently nicholasserra didn't find it either. ^_^ |
| 00:07 | <gsnedders> | TabAtkins: I dunno, the documentation isn't that great, I know. |
| 00:08 | <gsnedders> | At some point we'll get to 1.0 and have decent docs. :) |
| 00:09 | <TabAtkins> | It would be cool if alphabetical_attributes were on by default, because almost everyone either (a) doesn't care, or (b) needs some sort of stable attribute order but probably doesn't know it. |
| 00:09 | <TabAtkins> | The set of people who (c) don't need stable order and don't want to pay the cost, is so small to not ever matter I suspect. ^_^ |
| 00:10 | <nicholasserra> | Looks good locally, we'll see if it passes CI ^_^ thanks gsnedders TabAtkins |
| 00:10 | <gsnedders> | TabAtkins: or (d) wants to rely upon the defined-undefined lxml stable ordering |
| 00:10 | <gsnedders> | TabAtkins: (see fantasai) |
| 00:10 | <TabAtkins> | "stable" |
| 00:10 | <TabAtkins> | What? How does fantasai want to rely on that? |
| 00:11 | <gsnedders> | Wants ordering to roundtrip |
| 00:11 | <gsnedders> | I can't remember. She had seem decent reason. :) |
| 00:11 | <gsnedders> | *some |
| 00:11 | <TabAtkins> | Attributes are unordered anyway. Depending on attribute order is the devil's work. |
| 00:12 | <gsnedders> | I think it was to do with readibility of parsed/serialized documents, and having an order that aids readability |
| 00:12 | <zewt> | defined undefined and actually having actively unstable order (eg. hash order) is fine, what's evil is APIs that appear to be in a nice, obvious order (like alphabetical) but whose docs say "by the way we don't guarantee any order" |
| 00:13 | <gsnedders> | (AFAIK lxml does this because libxml2 does that, and it gets it by virtue of wrapping it, and doesn't want to provide further guarantees than the lower layer API) |
| 00:14 | <nicholasserra> | gsnedders: Can I use that shorthand method if i'm using HTMLSanitizer tokenizer? |
| 00:14 | <gsnedders> | nicholasserra: maybe? there might be a sanitize=True option or something? |
| 00:15 | <gsnedders> | nicholasserra: the docstring on HTMLSerializer will probably help? |
| 00:16 | <nicholasserra> | Looks like it can, awesome gsnedders |
| 00:17 | <gsnedders> | nicholasserra: (really I'm just guessing at what I'd have called that API if I introduced it now, I don't actually know off-hand :)) |
| 01:34 | <MikeSmith> | Hixie: http://validator.w3.org/nu/ is most up-to-date, currently |
| 01:42 | <a-ja> | MikeSmith: know if it now allows header content in <summary> ? |
| 01:46 | <MikeSmith> | a-ja: it allows whatever is in the trunk at https://github.com/validator/syntax/commits/master |
| 01:47 | <MikeSmith> | a-ja: https://github.com/validator/syntax/commit/d214cdf4e04a522205919bc1c92001ae547b8f30 |
| 01:53 | <a-ja> | MikeSmith: Error: XHTML element h2 not allowed as child of XHTML element summary in this context. (Suppressing further errors from this subtree.) |
| 01:55 | <MikeSmith> | a-ja: you're testing from teh command line? |
| 01:55 | <a-ja> | MikeSmith: same in text/html, so perhaps that hasn't been committed? |
| 01:55 | <MikeSmith> | yeah it's been committed |
| 03:22 | <Hixie> | MikeSmith: ah. so what's the story with <table border>? i am going through old bugmail and i've come across conflicting bugs on it. In one, though, you said you'd decided to make it an error? the current validator makes it a warning, AFAICT. (just curious) |
| 03:26 | <MikeSmith> | Hixie: the only place it's not an error is in the W3C service. I was compelled to make it a warning there due to some idiot WG decision that was made way back when, based on a change proposal from Leif |
| 03:26 | <MikeSmith> | I opened a new HTML WG bug for thatーhttps://www.w3.org/Bugs/Public/show_bug.cgi?id=24591 |
| 03:28 | <cabanier> | MikeSmith: https://bugs.webkit.org/show_bug.cgi?id=132460 landed :-) so canvas should have correct behavior for non-finite value in the WebKit |
| 03:28 | <MikeSmith> | cabanier: nice. so is that in the latest nightly already? |
| 03:29 | <cabanier> | MikeSmith: should be there tomorrow if they are able to build one |
| 03:29 | <MikeSmith> | ok |
| 03:29 | <MikeSmith> | cabanier: does this mean you fixed the general WebIDL nonconformance in WebKit? |
| 03:30 | <MikeSmith> | damn that's a lot of patches |
| 03:30 | <cabanier> | MikeSmith: no, just for canvas. I was going to do the other interfaces too but that introduced too many changes |
| 03:30 | <MikeSmith> | ok |
| 03:30 | <MikeSmith> | well it's still a win |
| 03:30 | <cabanier> | MikeSmith: if you know of issues there, let me know |
| 03:31 | <MikeSmith> | cabanier: will do. thanks for taking time to fix this |
| 03:31 | <MikeSmith> | since Firefox was already passing those tests, I think that means we'll get the less-than-two-passing list down further |
| 03:32 | <MikeSmith> | http://w3c.github.io/test-results/2dcontext/less-than-2.html |
| 03:33 | <MikeSmith> | actually if you fix covers all those *nonfinite* cases, that'll reduce the list by 5 and bring it down to just 3 tests |
| 03:35 | <MikeSmith> | actually I should back out that hit-regions test anyway, since it really wasn't done the right way and it wouldn't be providing much coverage even if it was done right, since it's only testing one small part of the hit-regions spec |
| 03:39 | <MikeSmith> | cabanier: btw I don't know how to build a full WebKit binary (e.g., WebKit.app on OS X), as opposed to just building DumpRenderTree |
| 03:41 | <cabanier> | MikeSmith: if you can build dumprendertree, you have a working webkit. Just execute the "run-safari" script and it should launch |
| 03:41 | <cabanier> | MikeSmith: 2dcontext/fill-and-stroke-styles/2d.pattern.image.broken.html has not landed yet but I will try for tomorrow |
| 03:41 | <cabanier> | (I have questions for the reviewer) |
| 03:44 | <MikeSmith> | cabanier: ok, thanks |
| 03:48 | <MikeSmith> | cabanier: are there tests for hit regions somewhere? |
| 03:49 | <cabanier> | MikeSmith: I have one in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=979692 |
| 03:50 | <cabanier> | MikeSmith: I had another demo that I'm looking for right now |
| 03:50 | MikeSmith | looks |
| 03:50 | <MikeSmith> | cabanier: Gecko's the only UA the support hit regions at this point, right? |
| 03:51 | <cabanier> | MikeSmith: as soon as the patch goes in, yes :-) |
| 03:51 | <MikeSmith> | ok |
| 03:53 | <MikeSmith> | cabanier: I'm trying to remember why it was decided to keep hit regions in the CR document, given that we don't have any tests for it and we only have one UA that's going to support it any time soon |
| 03:54 | <cabanier> | MikeSmith: other example: http://codepen.io/anon/pen/zEsxa?editors=101 |
| 03:55 | MikeSmith | looks |
| 03:55 | <cabanier> | MikeSmith: the a11y people refused to let us go to CR unless there was a way to make canvas accessible |
| 03:56 | <cabanier> | MikeSmith: that example will only work with a firefox build that supports hit regions |
| 03:57 | <MikeSmith> | cabanier: is there some buildtime flag I need to set to do that? or I just need to manually apply your patch and build? |
| 03:57 | <cabanier> | MikeSmith: If you wait for this try build to finish: https://tbpl.mozilla.org/?tree=Try&rev=41f00121067b |
| 03:58 | <cabanier> | MikeSmith: you can download the build from there and unzip it locally. Then run -> about:config -> canvas.hitregions.enabled |
| 03:59 | <MikeSmith> | cabanier: by making the refusal they're ensuring that the 2dcontext document will not go to Rec this year. I don't see any way that the Director is going to approve transition of that document without tests. And without hit regions being supported in at least 2 engines. And I don't see that happening by the end of this year. |
| 03:59 | <SamB> | MikeSmith: they may not care |
| 03:59 | <MikeSmith> | cabanier: OK, thanksーwill give it try |
| 03:59 | <MikeSmith> | SamB: they care |
| 04:00 | <MikeSmith> | SamB: I think they just imagine that some magic is going to happen |
| 04:00 | <SamB> | you mean they mind, or they intend this? |
| 04:00 | <SamB> | oh |
| 04:00 | <SamB> | so they're just insane then |
| 04:00 | <MikeSmith> | no comment |
| 04:01 | SamB | assumes that means "yes" |
| 04:01 | <cabanier> | MikeSmith: it didn't seem like we had a choice. I would still like them to be as at-risk |
| 04:01 | <SamB> | I don't think what the spec sasy re: their being at-risk has any relevance on the reality that they are |
| 04:07 | <Hixie> | MikeSmith: ah, ok. any idea when henri's instance will be updated? |
| 04:07 | <MikeSmith> | cabanier: you have a choice actually. You're the ones with your names on the document. If anybody has a choice it's you. You just tell them no. If they want to object, they can object to the Director and I then spend 20 seconds on the transition call explaining that we dropped a feature from the document because we had no shipping implementations for it and no tests for it. |
| 04:07 | <MikeSmith> | Hixie: no idea. Henri's not had much time for it for a while. |
| 04:07 | <MikeSmith> | Hixie: I can run an conforming instance of it elsewhere |
| 04:08 | <Hixie> | oh there's no rush |
| 04:08 | <Hixie> | i'm just curious |
| 04:17 | <cabanier> | MikeSmith: we should have done that. The process has stalled for so long that the spec is already out of date :-( |
| 04:39 | <MikeSmith> | Hixie: I just set up a conforming instance of the validator at http://sideshowbarker.net:8888/ and will keep it up to date with changes |
| 04:42 | <MikeSmith> | Hixie: if it'd be possible to run a validator at validator.whatwg.org I'd be happy to maintain it. Either actually running on your dreamhost or with the DNS set up to point to http://sideshowbarker.net:8888/ or wherever |
| 05:42 | <Hixie> | MikeSmith: i think it'd be as much of a mistake for the whatwg to run a validator as it is for the w3c to run one. it implies that it is canonical, and discourages competition. the w3c validator was a disaster in the html4 days for exactly that reason -- completely stalled validator development until we started the new html spec. |
| 05:51 | <MikeSmith> | Hixie: well I wish some other people would run public instances of the validator. But I guess I can lead by example can keep the one running at sideshowbarker.net |
| 05:52 | <Hixie> | what i'd like is more independent implementations of validators |
| 05:52 | <MikeSmith> | well, that too |
| 06:20 | <caitp> | if html5 is a new spec, then surely breaking changes from html4 brokenness are both valid and welcome |
| 06:21 | <SamB> | caitp: only if nobody used that brokenness (especially if it was never implemented) |
| 06:22 | <caitp> | flush those deprecated broken apis and build anew 8) |
| 06:29 | <SamB> | you're confusing us with the xhtml 2 people |
| 06:31 | <caitp> | oh not at all, I would never |
| 06:33 | <caitp> | if anything, I'm confusing you with people who care about a sane platform 8) but with a sense of humour, of course |
| 06:41 | <MikeSmith> | caitp: will try to review your web-platform-tests PRs unless somebody else gets to them first |
| 06:42 | <caitp> | cheers |
| 07:50 | <tobie> | darobin: hey, trying to run webidl2.js test suite to no avail (plenty of tests are failing). Is this a know issue, a bug, or a problem with my setup. |
| 07:51 | <darobin> | tobie: saw the bug, I'll look at it in ~30min tops |
| 07:51 | <darobin> | it's not normal |
| 07:51 | <tobie> | ty |
| 07:51 | <darobin> | tobie: just off the top of my head, you have submodules set up? |
| 07:52 | <tobie> | Yes. I had issues with JSCOV stuff, but fixed that in the PR I sent you. |
| 07:52 | <tobie> | So these issues are on the patched version. |
| 07:53 | <tobie> | Without the patch, I just error at load time of invalid.js |
| 08:24 | <zcorpan> | mathiasbynens: you can remove "unicorn⊙1j 1x, " (redundant with src) |
| 08:25 | <darobin> | tobie: all tests pass here |
| 08:25 | <darobin> | can you paste the error logs online? |
| 08:25 | <zcorpan> | mathiasbynens: also, is it really wise to suggest 3x and 4x images right now? sure there are such screens but do you see visual difference from 2x? is it worth the extra bandwidth? |
| 08:27 | <mathiasbynens> | zcorpan: oh cool, didn’t know src is used for `1x` by default |
| 08:27 | <mathiasbynens> | zcorpan: i wanted to include 3x and 4x to recognize that such screens exist… felt bad omitting them |
| 08:28 | <zcorpan> | mathiasbynens: would you use 3x and 4x images in production on a site? |
| 08:28 | <mathiasbynens> | zcorpan: i don’t know. i’ve never had the pleasure of using a 3x/4x screen |
| 08:29 | <zcorpan> | what do you think happens with the file size of a 4x image? |
| 08:30 | <mathiasbynens> | sure, it blows up |
| 08:31 | <zcorpan> | yep, and worse you probably wouldn't be able to tell the difference from a 2x image on a 4x screen unless you literally put your nose to the screen |
| 08:33 | <darobin> | zcorpan: so... there's a Google Glass use case? |
| 08:33 | <tobie> | darobin: darn, here's the dump: https://gist.github.com/tobie/c3e5897aa8339f225b64 |
| 08:33 | darobin | gets his coat |
| 08:33 | zcorpan | slaps darobin with darobin's google glasses |
| 08:34 | <darobin> | :) |
| 08:34 | <darobin> | tobie: hmmm, so all the AST tests fail, basically? |
| 08:34 | <darobin> | that looks bad |
| 08:35 | <zcorpan> | mathiasbynens: in practice i've seen people use 1x, 1.5x and 2x |
| 08:35 | <tobie> | darobin: pretty much, yes. |
| 08:35 | <darobin> | tobie: are you running against the very latest develop? |
| 08:36 | <jgraham> | zcorpan: The file size stays the same (you didn't say which image, so I'm assuming it's just a solid colour)? Do I win? |
| 08:36 | <mathiasbynens> | the 1.5x being for non-retina iPads and such? |
| 08:36 | <tobie> | darobin: running against a patched version of latest develop |
| 08:36 | <zcorpan> | jgraham: i also didn't say what the compression was, so the bigger image might be smaller in file size |
| 08:37 | <darobin> | tobie: what's the version of jsondiffpatch you're using? |
| 08:37 | <zcorpan> | mathiasbynens: don't remember about iPads but there are phones with 1.5x iirc |
| 08:37 | <darobin> | grep version node_modules/jsondiffpatch/package.json |
| 08:38 | <tobie> | darobin: 0.1.5 |
| 08:38 | <darobin> | mmmmmmm |
| 08:38 | <darobin> | tobie: try using 0.0.5 just for kicks |
| 08:38 | <darobin> | this is old code, nowadays I hardcode versions for absolutely everything |
| 08:39 | <zcorpan> | mathiasbynens: http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density |
| 08:40 | <tobie> | darobin: surprisingly better, but not there yet. |
| 08:40 | <tobie> | dump comming |
| 08:40 | <darobin> | tobie: well if it's better that's already a plus |
| 08:40 | <tobie> | ^ did I just write that? |
| 08:40 | <darobin> | fucking libs that break their interfaces |
| 08:41 | <darobin> | heh |
| 08:41 | <tobie> | Well, that's what semver is for. |
| 08:41 | <darobin> | yeah, but you'd hope that a lib that returns undef when there's no difference would stick to that |
| 08:41 | <darobin> | besides, they upped a minor version — so not doing sember |
| 08:41 | <darobin> | semver |
| 08:43 | <tobie> | https://gist.github.com/tobie/ba05228b7377b812650c |
| 08:45 | <tobie> | darobin: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." |
| 08:45 | <tobie> | http://semver.org/ |
| 08:45 | <darobin> | tobie: fair enough, except that 90% of projects stick to 0.y.z for the entirety of their lifetime... |
| 08:46 | <tobie> | (which incidentally is why no one that does semver releases a 1.0 version these days) |
| 08:46 | <tobie> | absolutely. |
| 08:46 | <darobin> | tobie: can you give me the value of npm outdated? |
| 08:46 | <darobin> | which sort of defeats the point |
| 08:46 | <tobie> | agreed |
| 08:48 | <tobie> | https://gist.github.com/tobie/f201be91888ae032a540 |
| 08:49 | <darobin> | mmmm, not that |
| 08:49 | <darobin> | I really don't see what's wrong |
| 08:49 | <darobin> | node -v ? |
| 08:51 | <darobin> | also this is just basic JS, it's not depending on anything crazy |
| 08:51 | <darobin> | it really should be portable |
| 08:52 | <darobin> | tobie: do you get the same failures if you clone a clean copy off GH? |
| 08:53 | <tobie> | node: v0.10.22 |
| 08:53 | <tobie> | let me start again from a clean repo |
| 08:53 | <tobie> | (Well, except I'm going to be missing the JSCOV patch and the right jsondiff version |
| 08:53 | <tobie> | so that's probably not going to work. |
| 08:56 | <darobin> | tobie: I applied your PR |
| 08:56 | <darobin> | and I've just pushed a change to the jsondiff version |
| 08:56 | <darobin> | so a clean repo, branch develop, should be exactly what I have |
| 08:56 | darobin | needs coffee |
| 08:58 | <tobie> | works. |
| 08:58 | <tobie> | o_O |
| 08:58 | <darobin> | ah HA! |
| 08:58 | darobin | whacks tobie |
| 08:59 | tobie | whack darobin back with darobin's google glasses |
| 09:02 | <tobie> | darobin: Thanks. |
| 09:04 | <darobin> | np |
| 09:04 | <darobin> | I guess now you can go on to fixing the Promise bug :) |
| 09:10 | <tobie> | heh |
| 09:11 | <tobie> | (I was wondering why I was doing all of this. Thanks for reminding me.) |
| 09:11 | <tobie> | (No longer sure what I need the promise bug fixed for, however) |
| 09:11 | <darobin> | for SCIENCE! |
| 09:11 | <tobie> | Found the cause of the earlier breakage: git pull origin master |
| 09:11 | <tobie> | in the submodule (as recommended in the README) |
| 09:12 | <tobie> | FYI |
| 09:12 | <Ms2ger> | "git pull" is, AIUI, a feature introduced to fuck up people who come from HG |
| 09:13 | <tobie> | Ms2ger: that's actually not what the problem here is. |
| 09:13 | <tobie> | Ms2ger: but that's an interesting theory. Do you think Linus did that on purpose? |
| 09:14 | <Ms2ger> | Well, it's Linus |
| 09:14 | <Ms2ger> | No other comment. |
| 09:18 | <zcorpan> | hmm. http://stackoverflow.com/questions/10524578/how-to-move-a-file-from-one-git-repository-to-another-while-preserving-history on html-mirror seems it consumed all of my memory. waiting for it to finish using swap would probably take all day if it would finish at all :-( |
| 09:19 | <zcorpan> | anyone have ideas how i should preserve the history of the `source` file? |
| 09:19 | <zcorpan> | maybe i can keep the other things in history also |
| 09:23 | <zcorpan> | jgraham: ^ |
| 09:24 | <zcorpan> | i want to take `source` and put it into https://github.com/ResponsiveImagesCG/picture-element/ along with the history |
| 09:25 | <zcorpan> | but not necessarily the history of the other files |
| 09:25 | <darobin> | zcorpan: is it a problem if you just incorporate the whole repo and then delete the other files? |
| 09:26 | <zcorpan> | darobin: i guess not |
| 09:27 | <zcorpan> | how do i do that? |
| 09:27 | <Ms2ger> | Didn't someone already have a git clone? |
| 09:28 | <zcorpan> | http://bpeirce.me/moving-one-git-repository-into-another.html |
| 09:28 | <Ms2ger> | One of the Philip's? |
| 09:28 | <zcorpan> | Ms2ger: yes, i've forked it already |
| 09:28 | <Ms2ger> | Ah |
| 09:28 | <zcorpan> | dunno if i needed to fork it but anyway |
| 09:29 | <zcorpan> | https://github.com/zcorpan/html-mirror |
| 09:52 | <tobie> | darobin: where do you want me to put the WebIDL for the tests? |
| 09:53 | <darobin> | tobie: wherever makes sense under tests |
| 09:53 | <tobie> | darobin: well the other ones are in widlproc |
| 09:53 | <darobin> | tobie: I know |
| 09:54 | <tobie> | which we can't update as it breaks existing tests |
| 09:54 | <darobin> | one option is that you could submit that to widlproc, but that looks like it'll be painful |
| 09:54 | <darobin> | so just create a new dir I guess |
| 09:54 | <tobie> | k. |
| 09:54 | <tobie> | are you using widlproc for anything but those ? |
| 09:54 | <darobin> | nope |
| 09:55 | <tobie> | why do't you just dump all the tests in the main project, then? |
| 09:55 | <tobie> | And remove the submodule dep? |
| 09:57 | <Ms2ger> | But shared tests! |
| 09:57 | <darobin> | tobie: over time it may make no difference |
| 09:58 | <darobin> | back when I made it, dom was updating his tests a lot so keeping in sync made a lot of sense |
| 09:58 | <darobin> | or at least, it made my life easy |
| 09:58 | <tobie> | Ms2ger: go away, you. |
| 09:59 | <Ms2ger> | :'( |
| 09:59 | <darobin> | awwwww |
| 09:59 | <darobin> | tobie: if you want to just slurp things in, feel free |
| 09:59 | <darobin> | but be nice to Ms2ger |
| 10:00 | Ms2ger | goes and cries in a corner |
| 10:00 | <jgraham> | zcorpan: Yeah, it might be easier to just pull in all the history and then delete the files you don't want. Unless you really don't want them anywhere in the new repo |
| 10:01 | darobin | makes some hot cocoa for Ms2ger |
| 10:01 | <jgraham> | 3~With a hint of cyanide^Walmond? |
| 10:02 | <darobin> | I was more going for a touch of cognac, to keep him warm in the face of so much internet hatred |
| 10:03 | <Ms2ger> | Cognac with almond? |
| 10:03 | <darobin> | mmmmmm |
| 10:50 | <zcorpan> | jgraham: how do i do that, assuming i don't need to move anything to a different directory? |
| 10:52 | <jgraham> | zcorpan: Well I guess the easiest thing is git subtree add (original repo) |
| 10:52 | <jgraham> | You need a new-enough git to have subtree bundled |
| 10:53 | <zcorpan> | seems `git subtree` is there |
| 11:01 | <zcorpan> | what do i use as prefix= ? |
| 11:03 | <jgraham> | I don't think you need it |
| 11:03 | <jgraham> | Unless you want the file in a subdirectory |
| 11:05 | <zcorpan> | "You must provide the --prefix option." |
| 11:05 | <zcorpan> | "prefix '/' already exists." |
| 11:06 | <jgraham> | Oh |
| 11:06 | <jgraham> | Then maybe this isn't going to work in an easy way |
| 11:06 | <zcorpan> | :-/ |
| 11:06 | <zcorpan> | i guess it's ok to have it in a subdirectory if it makes things simpler |
| 11:06 | <jgraham> | Unless you do something like --prefix=import; git mv import/source ../ git rm import |
| 11:07 | zcorpan | tests |
| 11:15 | <zcorpan> | $ git subtree add --prefix=import https://github.com/whatwg/html-mirror.git HEAD # great success |
| 11:36 | <foolip> | zcorpan: what are you using html-mirror.git for? |
| 11:37 | <zcorpan> | foolip: i want to add <picture> to the html spec |
| 11:37 | <foolip> | ah |
| 11:37 | <foolip> | it has happened on occasion that my update script has broken, so if stops updating let me know |
| 11:38 | <zcorpan> | i just need a snapshot for this |
| 11:38 | <foolip> | ok, no problem then :) |
| 11:38 | <zcorpan> | it seems up-to-date right now (last commit 14h ago) |
| 11:38 | <foolip> | yeah, I unbroke it yesterday |
| 11:39 | <zcorpan> | good timing |
| 11:39 | <foolip> | yep, but it was only a few days behind |
| 11:40 | <zcorpan> | https://gist.github.com/anonymous/42438f0f244121748f11 - does this seem sane? |
| 11:41 | <foolip> | I suppose, but IANAL |
| 11:43 | <darobin> | zcorpan: shouldn't that license say something nasty about plagiarism? |
| 11:43 | darobin | runs away fast and giggling |
| 11:43 | <zcorpan> | i slap people with their google glasses instead |
| 11:44 | <darobin> | :) |
| 12:01 | <zcorpan> | i think i didn't screw up... https://github.com/ResponsiveImagesCG/picture-element/pull/173 |
| 12:02 | <zcorpan> | although github complained twice, it seems it went through ok |
| 12:05 | <zcorpan> | hmm. is it licence or license here? |
| 12:11 | <annevk> | license |
| 12:12 | <jgraham> | Two cs appears to be en-gb |
| 12:12 | <annevk> | or en-ca I suppose |
| 12:16 | <zcorpan> | not sure if something is broken or github is slow. the spelling fix doesn't show up in the PR |
| 12:35 | <zcorpan> | hmm, seems anolis doesn't do data-x="" |
| 12:50 | <Ms2ger> | Nope |
| 12:50 | <Ms2ger> | That's a Hixieism, like most of the spec |
| 12:51 | <annevk> | mounir: https://bugzilla.mozilla.org/show_bug.cgi?id=920734#c8 |
| 13:06 | <foolip> | annevk: wtf? http://resources.whatwg.org/logo-xhr.svg |
| 13:06 | <annevk> | foolip: yes? |
| 13:06 | <foolip> | what is it? |
| 13:06 | <annevk> | it's Ajax, of course |
| 13:06 | <annevk> | way big in 2005 and still big if you're into soccer |
| 13:07 | <tobie> | darobin: trying to add support for type pairs (http://heycam.github.io/webidl/#proddef-ExtendedAttributeTypePair) to webidl2.js. |
| 13:07 | <annevk> | (although I'm not sure if they're doing that great) |
| 13:07 | <foolip> | oh, the logo of a soccer team :) |
| 13:07 | <foolip> | that's cute |
| 13:07 | <Ms2ger> | We have a clever punster in annevk |
| 13:08 | <jgraham> | Probably some kind of copyright violation :) |
| 13:08 | <tobie> | plagiarism. No less. |
| 13:08 | <foolip> | http://resources.whatwg.org/logo-mime.svg is cute too |
| 13:12 | <annevk> | tobie: o_O |
| 13:12 | <tobie> | :) |
| 13:15 | <darobin> | zcorpan: if you need tools that can process "source" you can dig inside https://github.com/w3c/html-tools |
| 13:17 | <tobie> | darobin: how do you handle precedence within the parser? Plus backtracking? Seems type pairs should come after arg lists, but then a whole bunch of tokens will have been consumed already. |
| 13:19 | <darobin> | tobie: I backtrack by pushing tokens back onto the tokens array |
| 13:20 | <darobin> | then trying the next rule |
| 13:21 | <tobie> | k |
| 13:21 | <tobie> | ty |
| 13:24 | <annevk> | Domenic_: if you feel up to a challenge, https://wiki.mozilla.org/B2G/Bluetooth/WebBluetooth-v2 |
| 13:24 | <annevk> | Domenic_: review request is on Mozilla dev-webapi |
| 13:24 | <annevk> | Domenic_: not sure we'll ever expose that to the web |
| 13:24 | annevk | is still a bit unsure what the best way to deal with random hardware is |
| 13:26 | <darobin> | Discovery API plus make everything look like HTTP? |
| 13:36 | <annevk> | darobin: I think WebSocket or WebRTC might be better? Especially for stuff like AirPlay |
| 13:36 | <darobin> | annevk: it depends on the devices, some of them really have more or an HTTP model (a lot of ZigBee) |
| 13:37 | <darobin> | annevk: but what I meant by "HTTP" was, you know, the whole basic Web protocol stack |
| 13:37 | <Domenic_> | Fun stuff. |
| 13:37 | <darobin> | so yes, WS, HTTPS, whatever can already be used from the APIs we have |
| 13:38 | <darobin> | I don't recall enough of the BT details to remember if it can be mapped easily |
| 13:38 | <Domenic_> | No glaring problems jump out. Would be nice if we had Object.observe instead of onattributechange. |
| 13:38 | <darobin> | the nice thing with Discovery is that it handles the origin whitelisting |
| 13:39 | <Domenic_> | I think hardware-specific APIs are fine. what's the argument against? |
| 13:40 | <darobin> | you have to define and implement a very long list of them |
| 13:42 | <darobin> | Domenic_: case in point https://rawgit.com/w3c/automotive-bg/master/snapshots/vehicle_spec_snapshot20140425.html |
| 13:42 | <Domenic_> | Mmm, so we're lazy? seems not so good. iOS team is not lazy. windows team is not lazy. |
| 13:42 | <darobin> | CAUTION, NSFS |
| 13:43 | <Domenic_> | but! in this case, defining USB would suffice, I believe |
| 13:43 | <Domenic_> | then you emscripten some Bluetooth drivers |
| 13:43 | <darobin> | maybe we just care more about our users' security? |
| 13:43 | <zcorpan> | darobin: thx, i'll have a look |
| 13:44 | <Domenic_> | I don't think security and hardware access are mutually exclusive… |
| 13:45 | <mounir> | annevk: ta |
| 13:49 | <jgraham> | I think characterising "we find it difficult to create a large number of specs with a consistent feel and high quality" as "we're lazy" is rather unhelpful. |
| 13:50 | <Ms2ger> | Fair |
| 13:50 | <Ms2ger> | We're still lazy, though |
| 13:50 | <darobin> | lol |
| 13:50 | <jgraham> | In the sense that it's perjorative and so tends to shut down discussion of how we can achieve the goals we want within the constraints we have |
| 13:51 | <darobin> | a relatively generic solution also means we can avoid playing catch up |
| 13:51 | <darobin> | Domenic_: re mutually exclusive I don't think either, but on iOS they are |
| 13:51 | <darobin> | and if we are to make this work, we need a clear security model |
| 13:52 | <darobin> | we can create a new one (so far, an abject failure from all who have tried), or we can try to reuse the one we have (which is Discovery's approach) |
| 13:52 | <darobin> | I'm not saying it's impossible, in fact I think it's very much doable, but doing it requires a little bit more than "not being lazy" :) |
| 13:52 | <darobin> | anyway, I'll get back to slouching in front of kitten pics |
| 13:59 | <mathiasbynens> | annevk: packages for each legacy single-byte encoding in the Encoding Standard |
| 13:59 | <mathiasbynens> | http://mths.be/ibm866 http://mths.be/iso-8859-10 http://mths.be/iso-8859-13 http://mths.be/iso-8859-14 http://mths.be/iso-8859-15 http://mths.be/iso-8859-16 http://mths.be/iso-8859-2 http://mths.be/iso-8859-3 http://mths.be/iso-8859-4 http://mths.be/iso-8859-5 http://mths.be/iso-8859-6 http://mths.be/iso-8859-7 http://mths.be/iso-8859-8 |
| 13:59 | <mathiasbynens> | http://mths.be/iso-8859-8-i http://mths.be/koi8-r http://mths.be/koi8-u http://mths.be/macintosh http://mths.be/windows-1250 http://mths.be/windows-1251 http://mths.be/windows-1252 http://mths.be/windows-1253 http://mths.be/windows-1254 http://mths.be/windows-1255 http://mths.be/windows-1256 http://mths.be/windows-1257 http://mths.be/windows-1258 |
| 13:59 | <mathiasbynens> | http://mths.be/windows-874 http://mths.be/x-mac-cyrillic |
| 13:59 | <mathiasbynens> | </spam> |
| 14:06 | <zcorpan> | Ms2ger: i don't remember how bitbucket works but i'd like to send a PR of https://bitbucket.org/zcorpan/anolis/branch/support-data-x |
| 14:08 | Ms2ger | clicks the "Create pull request" button |
| 14:09 | <jgraham> | zcorpan: It seems that the process is that you get Ms2ger to click the "Create pull request" button :p |
| 14:09 | <annevk> | mathiasbynens: that looks like so much cruft |
| 14:09 | <Ms2ger> | zcorpan, one comment: https://bitbucket.org/ms2ger/anolis/pull-request/12/support-data-x/diff |
| 14:10 | <zcorpan> | Ms2ger: oops |
| 14:10 | <annevk> | mathiasbynens: might be better to put some effort into getting TextEncoder / TextDecoder into ECMAScript |
| 14:10 | <Ms2ger> | Along with atob? |
| 14:11 | <annevk> | Domenic_: hardware gets obsoleted |
| 14:11 | <zcorpan> | Ms2ger: fixed |
| 14:11 | <annevk> | Domenic_: as in, something to control presentation slides makes sense, irrespective of whether that's connected through USB, Bluetooth, WiFi, or some future protocol |
| 14:12 | zcorpan | *poof* |
| 14:12 | <annevk> | Domenic_: the web should not bake in future-legacy |
| 14:12 | <annevk> | Lol bitbucket |
| 14:12 | <Ms2ger> | zcorpan: did you? |
| 15:00 | <annevk> | http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity-provider-selection o_O |
| 15:00 | <annevk> | Domenic_: has the TAG or anyone looked at that? |
| 15:00 | <annevk> | "In order to communicate with the IdP, the browser instantiates an isolated interpreted context, effectively an invisible IFRAME." I don't even |
| 15:02 | <annevk> | Domenic_: fyi, that's basically a new primitive |
| 15:04 | jgraham | isn't sure why annevk uses "the TAG" as a proxy for "the set of people competent to do architectural review" |
| 15:04 | <jgraham> | But yeah, you can't just throw that kind of thing into a spec like that |
| 15:05 | <Ms2ger> | Clearly you can |
| 15:05 | <annevk> | jgraham: not sure who else would pick it up |
| 15:05 | <Ms2ger> | We clearly need more architecture architectss |
| 15:06 | <jgraham> | annevk: Well it's a public mailing list I assume, so it could be anyone. The idea of having an elected group that is somehow more competent to review specs like that is very strange |
| 15:08 | <annevk> | jgraham: it's not about competence, it's about responsible |
| 15:08 | <annevk> | jgraham: I could take responsibility, but if I did that for every specification I'd be in trouble |
| 15:08 | <annevk> | jgraham: the TAG is quite a bit larger and have said they take that responsibility upon them, so if something is crap, we can blame them |
| 15:09 | <annevk> | jgraham: in addition to the WG |
| 15:09 | <jgraham> | I'm not interested in assigning blame |
| 15:09 | <jgraham> | I'm interested in getting good results |
| 15:09 | <annevk> | Right, turns out making people responsible for certain tasks is a good way of getting things done |
| 15:10 | <jgraham> | That doesn't seem to be working out so well |
| 15:10 | <annevk> | Citation needed |
| 15:10 | <jgraham> | The fact that you are running around after dozens of specs pointing out major mistakes? |
| 15:11 | <annevk> | jgraham: heh, there's a couple of specs that have been impacted by people from the TAG; I'm not sure it's working great, but it's working well and better than what we had before |
| 15:11 | <Domenic_> | Catching up... |
| 15:12 | <annevk> | jgraham: is there a better way? |
| 15:12 | <darobin> | the TAG certainly has improved |
| 15:12 | <jgraham> | Fundamentally I disagree with the idea of having an elected group with technical responsibilities. If the system was "all specs have to ask for review on www-tag which is a public mailing list rather than a group with membership", that would make a good deal more sense |
| 15:12 | <darobin> | the only better way I can think of requires having a larger involved community |
| 15:13 | <Domenic_> | annevk: I don't buy that argument about future-legacy. If Bluetooth goes out of style, nobody will use Bluetooth APIs. Same as in iOS. |
| 15:13 | <annevk> | jgraham: I think in practice that's largely how it works, the elected group thing feels like a sideshow |
| 15:13 | <darobin> | Domenic_: the problem isn't people using, the problem is implementation having to keep shipping with them |
| 15:13 | <Domenic_> | Hmm. |
| 15:13 | <Domenic_> | Why is this more a problem for browsers than for iOS? |
| 15:13 | <darobin> | over time, this accrues massive amounts of code that has potential flaws |
| 15:13 | <jgraham> | annevk: If that's how it works we should make that the real system and not pretend that there's an elected group with mandated responsibility |
| 15:13 | <jgraham> | that will somehow save us |
| 15:14 | <annevk> | Domenic_: iOS controls its entire ecosystem and has some level of versioning, the web doesn't |
| 15:14 | <darobin> | because iOS doesn't give a shit about obsoleting relatively large tracts of the store, plus they have email contacts for all content creators |
| 15:14 | <darobin> | we give a shit about not obsoleting much of the web, and we can't reach people |
| 15:14 | <annevk> | jgraham: okay, but is there a problem with meanwhile using the existing system as a replacement for the nothing we had before? |
| 15:15 | <Domenic_> | So you're imaging a future in which: (a) Bluetooth is a legacy technology; but (b) "relatively large tracts" of the web use Bluetooth APIs; and (c) browsers want to un-ship Bluetooth? |
| 15:16 | <jgraham> | annevk: I don't think think there's any "meanwhile". You either encourage a system where a semi-elected set of people are given special powers or you advocate not using those people. |
| 15:16 | <annevk> | Domenic_: what I want is that if you have a piece of hardware you don't have to care about Bluetooth vs USB vs X; the browser handles the connection abstraction for you |
| 15:17 | <annevk> | Domenic_: that way the code can outlive particular hardware interfaces |
| 15:17 | <Domenic_> | annevk: that seems unrealistic. I am very leery of catch-all leaky abstractions. |
| 15:17 | <jgraham> | Domenic_: It is quite possible that pages fail if the API doesn't exist, even if no one actually has the hardware |
| 15:17 | <JonathanNeal> | I’m a little confused by https://github.com/ThePacielloGroup/w3c-heading/blob/gh-pages/README.md anyone up on this and can break down what’s happening in element world? |
| 15:18 | <Domenic_> | jgraham: that seems solvable with API design. E.g. requestBluetooth().then(bluetoothThingy => ..., handleError) could always reject in Chrome 302, so all the code for the BluetoothThingy class no longer has to ship. |
| 15:19 | <annevk> | http://www.smbc-comics.com/index.php?db=comics&id=2939 heh |
| 15:19 | <Domenic_> | annevk: WebRTC is so hard for me to wrap my head around :(. Is this something people want to ship, or is it theorycrafting? |
| 15:19 | <Ms2ger> | Ship |
| 15:20 | <annevk> | (via JakeA via Lea) |
| 15:20 | <annevk> | Domenic_: https://groups.google.com/d/msg/mozilla.dev.platform/QiF18J4vccA/rDclGYmFPBEJ |
| 15:21 | <Domenic_> | Well the API design is shit but obviously that's not the most important thing here. |
| 15:21 | <jgraham> | Domenic_: Sure, you can try things like that. Although there are other problems (like the hardware is only used in niche environments but ends up shipping for everyone) |
| 15:22 | <jgraham> | s/but/but the api/ |
| 15:22 | <jgraham> | Fundamentally the nature of the web makes the the half life of technologies > 20 years (based on current observations) |
| 15:22 | <jgraham> | But on iOS it seems to be like 2 years then fuck you |
| 15:23 | <Domenic_> | I see what you mean, but I'm not sure our past experience is the best guide here. |
| 15:23 | <Domenic_> | That is, techniques for styling text and hardware access are very different |
| 15:23 | <Domenic_> | Hardware usefulness has its own lifecycle |
| 15:24 | <jgraham> | That could be true |
| 15:24 | <Domenic_> | Also, comparing to Windows might be easier than iOS, since they have similar back-compact requirements |
| 15:24 | <Domenic_> | I mean parallel port drivers still ship with Windows |
| 15:25 | <Domenic_> | But things do shift out of Windows, e.g. old printer drivers are now downloaded on demand instead of shipped in box |
| 15:25 | <jgraham> | Right |
| 15:26 | <jgraham> | Certainly I agree with the idea that giving some thought to how to clean things up when we have 2000 types of hardware supported and 1500 of them aren't used anymore |
| 15:26 | <jgraham> | makes sense |
| 15:28 | <Domenic_> | I wonder about the "ship USB, let them build their own Bluetooth drivers" approach. That sounds pretty bad now that I say it out loud though. |
| 15:30 | <jgraham> | I'm not sure I want every website implementing its own buggy version of usb |
| 15:30 | <jgraham> | *bluetooth |
| 15:32 | <Domenic_> | Yeah seems pretty bad. |
| 15:32 | <Domenic_> | annevk: filed https://github.com/w3ctag/spec-reviews/issues/28, but I feel pretty out of my depth on this WebRTC stuff. |
| 15:33 | <annevk> | https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ o_O |
| 15:34 | <Domenic_> | jgraham: I agree that the elected-ness of the TAG is not terribly important. A sideshow seems about right. But within the existing W3C system (which I am definitely not a fan of) it has a number of benefits. |
| 15:34 | <Domenic_> | E.g. people seem to respect the TAG name, so it's easier to start conversations as a TAG member than as a random guy who wants to come in to your closed community and start interjecting themselves into conversations. |
| 15:35 | <annevk> | Graph at the end is humbling |
| 15:35 | <Domenic_> | And the ceremony around it helps psychologically to help me feel like it's my "job" to work on this stuff |
| 15:35 | <MikeSmith> | annevk: incidenttally I'd have thought that Martin of all people at this point would have moved on to pushing for implementation of the ORTC spec (which as he alludes to in that thread Microsoft is supporting) rather than adding more features to the WebRTC spec and implementing them |
| 15:36 | <Domenic_> | If someone asks us for review on something that I'm not that interested in (e.g. WebRTC), I still feel responsible for helping them, instead of "sorry, no time for that." |
| 15:36 | <annevk> | MikeSmith: well Mozilla bought his vote, that's how this works, right? |
| 15:36 | <Domenic_> | Plus it certainly helps sell to employers using your time this way. |
| 15:36 | <MikeSmith> | annevk: :) |
| 15:36 | annevk | has no insight in WebRTC vs ORTC politics |
| 15:36 | <Domenic_> | WebRTC vs. ORTC is also something I need to understand better. wycats was looking into it a bit. |
| 15:37 | <annevk> | Yeah, I think it's the same with having your name at the top of the draft, it's your responsibility to fix it |
| 15:37 | <MikeSmith> | Martin used to be the single most articulate critic of the whole WebRTC design |
| 15:37 | <Domenic_> | His take, with a disclaimer of them being based on an hour of skimming, was that ORTC was arguing that WebRTC was the new WebSQL. |
| 15:37 | <annevk> | Ideally everyone would just work on everything, but it's hard to fragment yourself like that |
| 15:38 | <annevk> | Domenic_: seems like IndexedDB might be the new WebSQL with some of those LevelDB features |
| 15:38 | <jgraham> | Domenic_: It has negative side effects too though. Elections strongly favour old-boys-clubs and certain personality types. They also don't capture a diverse range of technical expertise so the fact that the TAG signs off on something can give a false impression that it's OK when actually it's not. |
| 15:38 | <Domenic_> | annevk: hah, yes, I agree. |
| 15:38 | <annevk> | Domenic_: or the JavaScript i18n API with its heavy dependence on ICU |
| 15:39 | <darobin> | annevk: the "red button" extra on that classic SMBC is also a nice touch :) |
| 15:39 | <MikeSmith> | ironic now that IndexedDB started out as something called WebSimpleDB. come a long way.. |
| 15:39 | <jgraham> | I mean all your arguments could be made about closed-membership WGs vs open membership ones |
| 15:40 | <jcgregorio> | annevk: I look forward to a future where *all* non-CPython implementations are faster than CPython :-/ |
| 15:41 | <Domenic_> | jgraham: I'm not really familiar with the different WG models, but as for the other points, I agree. I guess in the end you have to try to solve those by people-hacks, e.g. trying to elect people who will listen and actively seek out diverse tech expertise. |
| 15:42 | <Domenic_> | jgraham: I don't think those things are actively harmful though, or at least, not very. They just mean the system is not the best possible system. |
| 15:42 | <annevk> | As long as most communication happens through GitHub or the mailing lists, it doesn't really matter who is in what group |
| 15:42 | <annevk> | E.g. I'm not in any W3C group, but that hasn't really stopped me from contributing to anything |
| 15:42 | <Domenic_> | ++ |
| 15:43 | <jgraham> | Sure, but that's because we had a big push for openness |
| 15:43 | <jgraham> | The TAG has resisted that push in its formal organisation |
| 15:43 | <Domenic_> | Yeah I was just going to say, private mailing lists must die. |
| 15:43 | <Domenic_> | jgraham: what do you mean by that? |
| 15:56 | <Domenic_> | darobin: nice post |
| 15:57 | <darobin> | Domenic_: ta |
| 15:58 | <jgraham> | Domenic_: By "formal organisation" I mean in the way that it has Members who have to be elected, rather than letting anyone with the right interests and skills take part in the work without a divide between those who are in the club and those who are not |
| 15:59 | <Domenic_> | jgraham: what is the divide? |
| 16:00 | <jgraham> | Domenic_: You tell me. If there isn't one then we certainly shouldn't waste time electing people. If there is then we should fix the system so there isn't. |
| 16:01 | <Domenic_> | jgraham: Anyone can take part in the work. But you're saying it's also important to be on the weekly call and be invited to F2Fs without having to ask anyone for an invite? |
| 16:02 | <jgraham> | Domenic_: I think that it's important to have the option to do those things, yes |
| 16:02 | <jgraham> | (or for those things to not happen) |
| 16:03 | <Domenic_> | I wonder how well an open line for weekly standup would work, or an open-door policy for F2Fs |
| 16:04 | <Domenic_> | On another note: I'm in an EmpireJS talk right now basically about how to reimplement rich text editing on top of today's contenteditable clusterfuck. The lengths people go to... @_@ |
| 16:05 | <darobin> | Domenic_: there's movement on that front thankfully |
| 16:06 | <Domenic_> | E.g. listening to every possible mouse or keyboard input event, then diffing the before-and-after selection, with some semantic patch algorithm, in order to synthesize a selectionchange event or similar. |
| 16:06 | <darobin> | Domenic_: which project is that? |
| 16:07 | <Domenic_> | darobin: I think it's part of Wordpress; been tuning in and out so I kind of missed the intro. |
| 16:07 | <darobin> | oh that one |
| 16:07 | <annevk> | Domenic_: so e.g. WebApps is a group which does all its work in public, and sometimes interested people get together to hash something out, open to anyone |
| 16:08 | <annevk> | Domenic_: hasn't caused much problem |
| 16:08 | <darobin> | I forget which one it is; I need to reach out to them |
| 16:08 | <darobin> | but not today |
| 16:08 | <annevk> | Domenic_: typically nobody dials into a telcon if its optional, as that's a waste of time |
| 16:08 | <darobin> | there still are telcons? oh, right, there are |
| 16:55 | <annevk> | Ah darobin left |
| 16:59 | <annevk> | WebGL :-( |
| 16:59 | <annevk> | Well jgraham may be correct that there's no clear supervision of what crap goes on |
| 17:00 | <annevk> | http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ o_O |
| 17:09 | <jwalden> | annevk: by heavy dependence you mean in terms of how people are implementing it, right? |
| 17:09 | jwalden | briefly delurks |
| 17:09 | <annevk> | jwalden: is this about WebGL? |
| 17:10 | <jwalden> | annevk: <annevk> Domenic_: or the JavaScript i18n API with its heavy dependence on ICU |
| 17:10 | <annevk> | jwalden: ah yes |
| 17:10 | <annevk> | jwalden: Microsoft is the only alternative you have |
| 17:11 | <jwalden> | everyone uses the same png implementation (or at least same base code plus a few patches), right? |
| 17:11 | <jwalden> | that being libpng |
| 17:11 | <annevk> | jwalden: Opera used to have a different one |
| 17:11 | <jwalden> | ICU is certainly worse than that, but there's some precedent for monocultures under the hood, sadly :-\ |
| 17:12 | <jwalden> | none at the standards level, thankfully, in terms of enshrining one implementation, roughly |
| 17:13 | <IZh> | Hi! There is somewhat strange with page table of content in Embedded content section: http://developers.whatwg.org/embedded-content-1.html#embedded-content-1 The link at the end of the page points to 4.7.2. But there are no link to this page from the table of content. |
| 17:13 | <IZh> | How to get to 4.7.2 from the top of the site? |
| 17:14 | <annevk> | jwalden: well, WebGL |
| 17:14 | <annevk> | jwalden: was kind of hilarious at the time with Mozilla advocating a non-WebSQL approach but happily joining the WebGL train |
| 17:15 | <jwalden> | annevk: there are multiple competing implementations of OpenGL, tho, and bunches of drivers, aren't there? what do I not know about the tech underneath this? |
| 17:16 | <annevk> | jwalden: hmm, I thought it was mostly OpenGL vs DirectX; I guess OpenGL has many implementations though |
| 17:17 | <jwalden> | I'm not seeing any similarity between the situations, myself |
| 17:19 | <jgraham> | I thought everyone used the same shader verifier, or something |
| 17:19 | <jgraham> | Also WebRTC |
| 17:27 | <annevk> | dglazkov: I think it would be nice if we could sync native and custom elements for the callbacks |
| 17:27 | <annevk> | dglazkov: given that e.g. callbacks such as clone are invoked-near-synchronous, that might be good enough |
| 17:27 | <annevk> | (not sure if clone is defined yet) |
| 17:30 | <jwalden> | yeah, I dunno about ANGLE exactly |
| 17:30 | <jwalden> | or to some extent WebRTC, except I thought implementation and spec were proceeding at similar paces/lockstep-ish |
| 17:31 | <jwalden> | I assume the ANGLE linting is going to be included in the spec, tho I have no knowledge of this happening or not happening |
| 17:32 | <dglazkov> | annevk: yes! that's my aspirational goal as well |
| 17:33 | <annevk> | dglazkov: otherwise we're not really "explaining" the native system (if we can't change it) but rather we'll end up with two systems, which is kinda what I've been worried about from the start with components |
| 17:41 | <Hixie> | foolip: yt? |
| 17:41 | <Hixie> | foolip: is there a bug tracking the xhtml <input> bug? |
| 17:41 | <Hixie> | foolip: also, how does it handle cloning? |
| 18:01 | <Domenic_> | annevk: dglazkov: also https://github.com/dglazkov/html-as-custom-elements/issues/14 |
| 18:33 | <caitp> | it's impossible to prove conclusively that it won't "break the web", but it's obvious that it won't. websites with actual audiences that people actually view, have designers who avoid situations where it would break things |
| 18:33 | <caitp> | there is no use demanding a survey of millions of web applications, it's clear that if such applications do exist, they are not being actively maintained, and have no audience |
| 18:34 | <Hixie> | when we were speccing the HTML parser, we tried to remove the hack that makes <image> into a macro for <img> |
| 18:34 | <Hixie> | that affected something like 0.3% of the web |
| 18:34 | <Hixie> | which was too much and we had to change the parser. |
| 18:34 | <caitp> | it's a bit of a different scenario, nobody has a good reason to actually want to give the parser something that it will re-arrange |
| 18:35 | <caitp> | the way the parser works currently, it's a site bug |
| 18:35 | <Hixie> | i would be willing to bet money that we can't change the parts of the parser that rearrange content. |
| 18:35 | <caitp> | I'll put 5 bucks on it that we can |
| 18:35 | <caitp> | because 0 people will be upset about it |
| 18:35 | <Hixie> | back in 2005 when i did my scan of the web, i examined about 10 billion pages, and 97% of them had some sort of syntax error. 70% if you ignored the doctype missing and similar low-hanging fruit. |
| 18:36 | <caitp> | sure they'll have syntax errors, but it's really a different kind of error |
| 18:36 | <Hixie> | try it. get the chrome source code, change the parser to not do the "foster parenting", or to not do the "adoption agency", and browse the web with it. |
| 18:36 | <caitp> | and anyways, if they're okay with whatever nonsense the parser re-arranges it into, then they're probably okay with it not re-arranging it too |
| 18:37 | <caitp> | well, I'd have to find a site that still uses tables for layout to do that anyways, that's not as easy as it sounds |
| 18:38 | <Hixie> | http://google.com/ uses tables for layout. |
| 18:38 | <Domenic_> | (zing) |
| 18:38 | <Domenic_> | (ironic burn) |
| 18:39 | <Hixie> | Domenic_: yeah, i'm not actually sure why we do. not clear that we need to. but there you have it. |
| 18:39 | <Domenic_> | I always assume Google does weird things because at Google scale the laws of physics are different |
| 18:39 | <caitp> | does it depend on content re-arranging, though? |
| 18:39 | <Hixie> | Domenic_: there's some truth to that |
| 18:39 | <Domenic_> | E.g. they use weird source control because they have so much code |
| 18:40 | <caitp> | because depending on what is essentially a parser bug, seems unlikely |
| 18:40 | <Domenic_> | Invalid HTML because it saves bytes |
| 18:40 | <Hixie> | caitp: i sure hope not. but i haven't checked. my point was just that tables are used for layout a lot still. |
| 18:40 | <Hixie> | caitp: you have to understand that what you say seems unlikely is something that many of us here have, through many years of experience, painfully discovered over and over again is critical to the functioning of the web. |
| 18:41 | <Hixie> | caitp: i encourage you to do the experiments we've described. |
| 18:41 | <caitp> | I will make a build of content_shell with a changed parser |
| 18:41 | <Hixie> | caitp: because it will be quite illuminating, and nothing that i say can convince you quite as much as experiencing it first hand. |
| 18:41 | <caitp> | what if it still doesn't convince me? here's the thing |
| 18:41 | <Hixie> | well, then we'll see :-) |
| 18:42 | <annevk> | cabanier: I recommend to discuss name changes on the same forum as where the names were introduced |
| 18:42 | <caitp> | in its current state, it's really broken crap, it's inconsistent with the rest of the browser, and it's not a rational behaviour |
| 18:42 | <annevk> | cabanier: not doing that feels a lot like acting in "bad faith" |
| 18:42 | <caitp> | there is no justifiable reason for it, and the result of it is adding nonsense like is=* to custom elements to get around it |
| 18:42 | <wilhelm> | What is this rational behaviour you speak of? I haven't seen any of that on the Web. |
| 18:42 | <caitp> | this is just making things uglier, and therefore worse |
| 18:42 | <annevk> | cabanier: e.g. Hixie will change the specification if a couple of vendors got together and implemented the same proprietary API, but that does not mean it's a good idea |
| 18:43 | <Hixie> | caitp: believe me, nobody has a lower opinion of the state of HTML parsing than I. |
| 18:43 | <caitp> | so sometimes, to unbreak something that is crap, you have to break a few eggs, and if a few sites have rendering problems on a few browsers, it won't hurt |
| 18:44 | <caitp> | so, I will try an experiment with content shell, but I can pretty much tell you right now it isn't going to convince me that this insane behaviour should be left unchanged, unless people specifically opt into that broken behaviour somehow |
| 18:45 | <Domenic_> | annevk: thanks for handling that promises question; I had a hard time understanding what he was asking. |
| 18:45 | <Hixie> | man, amazon.com has a lot of tables still |
| 18:45 | <Domenic_> | Why would you break eggs? That seems dumb. |
| 18:45 | <caitp> | to make an omlette! |
| 18:45 | <Domenic_> | The eggs are fine as they are. |
| 18:45 | <annevk> | caitp: I recommend studying more specifications, they're full of insane behavior |
| 18:45 | <Domenic_> | Or see topic ;) |
| 18:46 | <caitp> | I've seen, anne :p but they ought to try to be less insane |
| 18:46 | <Domenic_> | For the future, sure |
| 18:46 | <Domenic_> | No reason to break things that work though |
| 18:46 | <annevk> | caitp: that requires changing all humans |
| 18:47 | <annevk> | caitp: if they're all "perfect", the web would be "perfect", and we wouldn't crave to change it, or some such |
| 18:47 | <caitp> | you're never going to get concensus from all humans about any technical spec |
| 18:47 | <annevk> | caitp: as it is, we're all a little bit crap, and it shows |
| 18:48 | <caitp> | but maybe it's worth making a small handful of people temporarily unhappy, for the sake of moving things forward in a better, more rational way |
| 18:48 | <annevk> | caitp: but we can't change it, as that would mean destroying someone else's creation |
| 18:48 | <caitp> | their creation would still exist, would it not |
| 18:50 | <annevk> | caitp: some permille is not a handful of people |
| 18:50 | <caitp> | most people aren't authoring websites, people people authoring websites aren't doing things like putting <divs> inside of <tables> because the parser will take them out of the table for them |
| 18:51 | <caitp> | I don't know that for sure just yet, but I'm confident that it's not very many |
| 18:53 | <caitp> | what can we do to figure this out, maybe make a fork of webkit look a message whenever content gets re-arranged by the parser, and set up a headless browser to crawl the top million sites or something and see how many messages get logged? |
| 18:54 | <Hixie> | chrome already has instrumentation to detect how often something happens. you could just add the instrumentation simon described on the bug in comment 10. |
| 18:54 | <annevk> | caitp: look up "use counters" for Chrome |
| 18:54 | <annevk> | caitp: for Gecko it'd be telemetry |
| 18:55 | <annevk> | caitp: I've come across sites that expect that in the past |
| 18:55 | <caitp> | yeah but that's not very headless, it would take forever to crawl through the top million sites manually ;) |
| 18:55 | <annevk> | caitp: Opera had bugs around it; implementing the HTML parser helped with those sites |
| 18:55 | <caitp> | I don't doubt that such sites exist |
| 18:55 | <annevk> | caitp: the idea behind use counters and telemetry is that the users of Chrome and Firefox do that for you |
| 18:56 | <caitp> | what I doubt is that there is a reason to care that they exist |
| 18:56 | <annevk> | caitp: so you get numbers that matter to actual end users, which seems to be roughly what you're after |
| 18:56 | <Domenic_> | I guess you just have to accept that we care more about not breaking the web than you do |
| 18:56 | <caitp> | I care about not breaking the web more than it already is |
| 18:57 | <caitp> | ideally, it can be made less broken than it already is, too |
| 18:57 | <Domenic_> | Then stop trying to break it. |
| 18:57 | <caitp> | removing inconsistent irrational behaviour is an improvement, even if it breaks a few insignificant sites |
| 18:57 | <caitp> | in irrelevant ways that at worst cause a graphical error |
| 18:57 | <Domenic_> | That depends on your priorities |
| 18:58 | <Domenic_> | We prioritize not breaking the web. You prioritize ... something about preferring less steps in the parser algorithm? |
| 18:58 | <caitp> | what I prefer is not causing authors to care about nonsense like the broken parser algorithm |
| 18:59 | <Domenic_> | Authors don't care about it. |
| 18:59 | <caitp> | except when they do |
| 18:59 | <Domenic_> | They just run validators |
| 18:59 | <caitp> | with custom elements, it's even worse than it was before, because now people have a more legitimate reason to use non-table content in a table |
| 18:59 | <caitp> | (for example) |
| 19:00 | <caitp> | is=* is just a hack around brokenness, and authors should not have to care about brokenness or use a hack to get around it |
| 19:01 | <zcorpan> | Ms2ger: https://bitbucket.org/zcorpan/anolis/commits/c2f1273d351914143df7e546175a141074b48adf |
| 19:01 | <annevk> | is=* is not really for that, it's mostly about browser internals checking for element name / namespace rather than class |
| 19:01 | <annevk> | it helps with <tr> sure, but I think it wasn't really designed as a hack around the parser, more as a hack around browser internals |
| 19:01 | <Domenic_> | I honestly don't understand is="", but I am pretty sure that's my fault. |
| 19:02 | <annevk> | Domenic_: you could read up on it ;-) |
| 19:02 | <caitp> | I wasn't able to find it without asking, because everything is split into about 2 dozen specs each these days |
| 19:02 | <caitp> | minimum |
| 19:03 | <caitp> | at any rate, there are backwards-compatible things that could be done to not break those sites (i've named some) |
| 19:04 | <Domenic_> | annevk: spec is uninformative on rationales, and articles give weak justifications that don't satisfy me. |
| 19:04 | <Ms2ger> | Fallback for non-supporting browsers and a11y, last I checked |
| 19:05 | <zcorpan> | mathiasbynens: i'm impressed by your work (the encodings) |
| 19:05 | <annevk> | Domenic_: the main reason I saw was that browsers would need major refactoring and CSS would need some kind of inheritance based selector (might be a good idea though) |
| 19:05 | <annevk> | Domenic_: e.g. HTMLButtonElement defines a set of behaviors, but you style it with button {} |
| 19:05 | <mathiasbynens> | zcorpan: i just wrote a script that generates all these |
| 19:05 | <annevk> | Domenic_: if you subclass HTMLButtonElement, you lose the styling |
| 19:05 | <Domenic_> | Ms2ger: the a11y thing is interesting. Again ties back to https://github.com/dglazkov/html-as-custom-elements/issues/14 |
| 19:06 | <annevk> | Domenic_: that's why you use id=*, partially |
| 19:06 | <mathiasbynens> | zcorpan: annevk's easily parseable index files make it simple |
| 19:06 | <Domenic_> | annevk: hmm, so that you get button's styles? |
| 19:06 | <caitp> | oh, by the way, I'm not saying taht there is necessarily no reason to use the 'is' attribute |
| 19:06 | <caitp> | but it should not be used as a hack around the parser |
| 19:06 | <annevk> | Domenic_: there's a bunch of other places that use "button" rather than "is HTMLButtonelement" too, unfortunately rationale is in email somewhere |
| 19:06 | <zcorpan> | mathiasbynens: yeah, i'm impressed that you make it simple :-) |
| 19:06 | <Domenic_> | Ms2ger: the fallback reasoning is good, at least for easy cases like <button is="fancy-button">. I don't know why I forgot it. |
| 19:08 | <zcorpan> | Ms2ger: if i need to jump through a hoop to make the typo fix materialize in the PR i'm happy to do it but i have no idea what i should do |
| 19:09 | <Ms2ger> | zcorpan, I'm looking |
| 19:09 | <zcorpan> | k :-) |
| 19:10 | <Ms2ger> | zcorpan, apparently you need to hit the PR button again, and then it updates the existing PR |
| 19:10 | <Ms2ger> | Anyway, merged |
| 19:10 | <Ms2ger> | Thanks for the patch |
| 19:11 | <zcorpan> | ok, thanks. (i didn't see a PR button to begin with though) |
| 19:11 | <zcorpan> | hmm. maybe that's because i'm not logged in |
| 19:11 | <zcorpan> | explains things |
| 19:11 | <Ms2ger> | Ah, that's plausible |
| 19:12 | <zcorpan> | clearer UI would be a grayed-out PR button with a speech bubble next to it saying i need to log in :-) |
| 19:31 | <zcorpan> | does http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js contain *all* defined terms? |
| 19:32 | <Hixie> | i think so |
| 19:32 | <zcorpan> | so why do we have html.json in xref? https://github.com/whatwg/xref/blob/master/xrefs/dom/html.py |
| 19:33 | <Hixie> | i am unfamiliar with that file |
| 19:33 | <Ms2ger> | It's generated from the former, no? |
| 19:34 | <zcorpan> | Ms2ger: html-generated.json is generated from html.json with links updated to point to multipage. but html.json isn't generated i think |
| 19:35 | <Ms2ger> | Oh, right |
| 19:35 | <zcorpan> | but if fragment-links.js contains all IDs we could drop html.json and just get all the data from fragment-links.js |
| 19:36 | <Ms2ger> | Even stuff like "i": "the-i-element", "id": "the-id-attribute",? |
| 19:36 | Ms2ger | wonders why that's done |
| 19:37 | <Ms2ger> | I don't know |
| 19:37 | <Hixie> | i recommend waiting til i replace my pipeline |
| 19:37 | <Hixie> | then i can just generate whatever you need |
| 19:37 | <zcorpan> | oh, fragment-links.js doesn't contain the terms. just the IDs |
| 19:38 | <zcorpan> | ok |
| 19:38 | <zcorpan> | Hixie: xref is used by basically all anolis specs |
| 19:39 | <Hixie> | right |
| 19:39 | <Hixie> | i'll be able to generate that, and whatever tab needs, etc |
| 19:39 | <Hixie> | and host it in a well-known location |
| 19:39 | <zcorpan> | ok yeah |
| 19:39 | <Hixie> | i hope to also do cross-refs the other way as part of this, eventually |
| 19:40 | <Hixie> | maybe just automatically parse the target specs, figure out the terms, and link that way |
| 19:41 | <zcorpan> | i think bikeshed does something like that |
| 19:41 | <zcorpan> | or the term database bikeshed uses |
| 19:41 | <zcorpan> | Hixie: does https://github.com/ResponsiveImagesCG/picture-element/pull/173/files look ok to you? |
| 19:44 | <Hixie> | this is just the current text extracted without changes? |
| 19:44 | <Hixie> | (plus the license) |
| 19:44 | <zcorpan> | yes |
| 19:44 | <Hixie> | lgtm |
| 19:44 | <zcorpan> | i preserved your history also |
| 19:45 | <Hixie> | is there a url i can fetch it from? |
| 19:45 | <Hixie> | i don't see a "raw" link on that page |
| 19:45 | <Hixie> | https://raw.githubusercontent.com/zcorpan/picture-element/add-html-spec/source ? |
| 19:45 | <zcorpan> | i guess it will show up here when it's merged https://raw.githubusercontent.com/ResponsiveImagesCG/picture-element/gh-pages/source |
| 19:45 | <zcorpan> | it's just a PR so far |
| 19:46 | <Hixie> | k let me know when there's a firm url |
| 19:46 | <Hixie> | (or file a bug) |
| 19:46 | <Hixie> | (that might be easier) |
| 19:46 | <zcorpan> | ok |
| 19:50 | <zcorpan> | Hixie: the non-normative section 4.7.1.2 Adaptive images got lost, but maybe that can just be dropped |
| 19:54 | <Hixie> | well presumably you'll have an equivalent replacement |
| 19:55 | <zcorpan> | yeah |
| 20:09 | <TabAtkins> | Hixie: It would be great if you used Shepherd's link db along with Bikeshed. More people using it means more improvements. |
| 20:09 | <Hixie> | i'm a ways from this being something i need to worry about :-) |
| 20:09 | <Hixie> | i expect i will try to get away without using a db at all |
| 20:10 | <TabAtkins> | I have relatively complicated link handling, but I think you're more explicit about things, so that might not be as necessary. |
| 20:10 | <TabAtkins> | The "db" is just a JSON file. ^_^ |
| 20:10 | <Hixie> | right, whatever form :-) |
| 20:10 | <Hixie> | i just mean, i'd figure out the IDs from just parsing the target spec's HTML |
| 20:11 | <TabAtkins> | Yeah, since you just link to IDs that may be sufficient. |
| 20:11 | <TabAtkins> | Bikeshed goes to lengths to allow you to just link the text and have it automatically figure out what term and what spec you're trying to refer to. |
| 20:12 | <Hixie> | i figure the spec already has to link to the target specs |
| 20:12 | <TabAtkins> | Wrt "what I need", the spec mainly just needs to indicate the type of the dfn. Bikeshed's got a taxonomy. |
| 20:12 | <Hixie> | so you just crawl all of those to figure out which you're referencing |
| 20:13 | <TabAtkins> | Bikeshedded specs rarely have to explicitly link to any other specs. |
| 21:18 | <zcorpan> | Hixie: merged now |
| 22:02 | <Hixie> | lol. i try to open an HTML file that has content-disposition:attachment in firefox |
| 22:03 | <Hixie> | firefox is like "oh hell no, i ain't opening this! wanna send it to chrome?" |
| 22:03 | <Hixie> | sure, firefox, throw chrome under the bus. :-P |
| 22:17 | <Hixie> | TabAtkins: any feedback on https://www.w3.org/Bugs/Public/show_bug.cgi?id=24991 ? in particular, what BBB should be? |
| 22:20 | <TabAtkins> | Oh, BBB should probably be a pseudo-class. |
| 22:23 | <kbrosnan> | Hixie: https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition/?src=ss |
| 22:23 | <Hixie> | TabAtkins: do you really think it's worth introducing a pseudo-class just for this? |
| 22:23 | <Hixie> | i mean, i agree in theory |
| 22:23 | <TabAtkins> | Yeah, sure. Modal dialogs seem usefully detectable. |
| 22:23 | <Hixie> | k |
| 22:24 | <Hixie> | do i just spec that out, or do i file a bug on selectors, or...? |
| 22:24 | <TabAtkins> | Preferably email www-style. |
| 22:25 | <Hixie> | k |
| 22:25 | <TabAtkins> | That way I can talk about it in the telcon tomorrow and agree to either add it to Selectors or let HTML define it. |
| 22:26 | <Hixie> | (are we working on anything that explains pseudo-classes? seems like this kind of thing can could up often with new components. we're already defining pseudo-elements of some sort, right?) |
| 22:26 | <TabAtkins> | For pseudo-classes, yes: http://dev.w3.org/csswg/css-extensions/ |
| 22:26 | <TabAtkins> | For pseudo-elements, no, not yet. |
| 22:26 | <TabAtkins> | But it's on my radar. |
| 22:27 | <Hixie> | cool |
| 22:28 | <Hixie> | hmm, neat ideas in that spec |
| 22:28 | <Hixie> | i look forward to it :-) |
| 22:29 | <Hixie> | message regarding :modal sent to www-style |
| 22:30 | <Hixie> | oh, crap, i failed to not give a suggested name. damnit. |
| 22:30 | <Hixie> | i specifically didn't want to give a proposed name, and i screwed up at the very end and didn't notice until i'd sent it |
| 22:30 | <Hixie> | -_- |
| 23:09 | <zcorpan> | my grep for foster parentings in webdevdata resulted in a 4.6 MB file :-| |
| 23:23 | <Hixie> | zcorpan: what did you search for? |
| 23:24 | <zcorpan> | Hixie: https://gist.github.com/zcorpan/c330049466a705f714b7 |
| 23:25 | <Hixie> | ah yeah, similar to what i tried |
| 23:25 | <Hixie> | i got so many hits that our internal system just told me to make the query more specific and that it couldn't give me the results |
| 23:27 | <caitp> | anyways, like I said on the bug, what if the spec were altered in a backwards compatible way? |
| 23:29 | <caitp> | like, don't reparent tags whose local name contains a hyphen (which is suggested in custom elements), or, don't reparent if the not in quirks mode, or... |
| 23:29 | <zcorpan> | caitp: see comment 21 |
| 23:29 | <zcorpan> | quirks mode doesn't help here |
| 23:29 | <caitp> | if you have element foo-bar, you probably don't care about old browsers |
| 23:30 | <caitp> | your app is probably not targeting old browsers |
| 23:30 | <zcorpan> | why wouldn't you care about old browsers for foo-bar? |
| 23:30 | <zcorpan> | you could use a custom elements polyfill for old browsers |
| 23:30 | <caitp> | because you're either using custom elements, or you're using a framework which targets modern browsers, like Angular or Ember |
| 23:31 | <zcorpan> | i don't see how either of those mean you don't care about old browsers |
| 23:32 | <zcorpan> | (old browsers here includes all browsers that exist today) |
| 23:32 | <caitp> | the frameworks in particular are working to make old browsers irrelevant, we don't want to care about them |
| 23:33 | <caitp> | we'd all be very happy if they just evaporated |
| 23:34 | <caitp> | and as for custom elements, well, if you do care about old browsers, you could use a hack like is=* |
| 23:34 | <zcorpan> | i think we're thinking different things about "old browser" |
| 23:34 | <caitp> | I'm not talking about netscape 2 |
| 23:34 | <zcorpan> | let's say browsers accept to do your change |
| 23:35 | <zcorpan> | in 1 year from now, firefox is first out to ship the change |
| 23:35 | <zcorpan> | then firefox is "new" and chrome, safari, opera, ie, everyone else is "old" |
| 23:35 | <zcorpan> | would you not care about everyone but firefox? |
| 23:35 | <caitp> | no, so here's what happens |
| 23:36 | <caitp> | change takes time, it takes time to make minor fixes, it takes time to make sure that the spec makes sense |
| 23:36 | <caitp> | but if we agree that we want something to be sensible in the future, this means committing to start fixing this stuff. and that doesn't mean it has to happen all at once |
| 23:37 | <caitp> | so you could say "well, we'll roll this in in a backwards compatible fashion, and drop the old way in 6-10 years" |
| 23:37 | <caitp> | nothing has to happen all at once, but it's good to have a direction to go in |
| 23:37 | <caitp> | and from my perspective, the direction for the web is not "make it more insane", but quite the opposite |
| 23:38 | <caitp> | so over some period of time, whether it's 5 years or 10, marriagebuilders.com and kingsex.eu can work to fix their layouts, if they still exist by then |
| 23:39 | <caitp> | (which is probably being optimistic) |
| 23:39 | <zcorpan> | there's no incentive for them to fix the markup |
| 23:39 | <caitp> | and even if their layouts break, a little bit, I'll bet most of them are still readable |
| 23:40 | <caitp> | and if they don't fix their markup, who cares? |
| 23:40 | <zcorpan> | i don't |
| 23:41 | <caitp> | their users are going to install a virtual machine to watch porn or something on ie11? |
| 23:41 | <caitp> | so what? |
| 23:41 | <caitp> | it's not a good reason to hold sanity back |
| 23:42 | <caitp> | I think we can make this work so that authors don't have to write unreadable garbage markup just to make poorly thought out parsing rules happy |
| 23:43 | <zcorpan> | i think you have it backwards how the parsing algorithm came into being |
| 23:43 | <caitp> | I know how it came into being |
| 23:43 | <caitp> | it doesn't have to continue to be irrational |
| 23:44 | <zcorpan> | then why do you say it is poorly thought out? |
| 23:44 | <caitp> | because it is |
| 23:44 | <zcorpan> | how? |
| 23:44 | <caitp> | inconsistent with the rules of the rest of the browser -> poorly designed |
| 23:44 | <caitp> | it's a shaky foundation that you don't want to build a house on |
| 23:45 | <zcorpan> | .... now i'm either very confused or i'm back to "i think you have it backwards how the parsing algorithm came into being" |
| 23:45 | <zcorpan> | anyway i need to sleep |
| 23:46 | <caitp> | I understand that they had some silly idea that they needed to deal with peoples crap markup in some way |
| 23:46 | <zewt> | (hint: starting with "everything you're doing is silly" isn't a very productive way to open a conversation) |
| 23:46 | <caitp> | but in this case in particular, it's complete crap, you don't re-arrange peoples markup, especially when there's no reason to |
| 23:47 | <caitp> | well, what else do you call it zewt, there's a lot of silly nonsense on the web |
| 23:47 | <zewt> | (another hint: start by asking why it's being done the way it is, since you don't appear to know) |
| 23:48 | <caitp> | okay, I'll take your hint and ask you |
| 23:48 | <caitp> | why do we feel it's necessary to re-arrange markup that someone purposefully wrote in some fashion |
| 23:49 | <zewt> | i'm the wrong person to ask, but my understanding is: if the spec demands that browsers do things which break existing webpages, even "silly crap" webpages, browsers won't do it and the spec becomes irrelevant |
| 23:49 | <zewt> | if you want details, especially about a particular case, ask the editor for the spec you're reading |
| 23:49 | <caitp> | I can understand that |
| 23:50 | <caitp> | I don't think the person who came up with the html parser is still doing this, they must be in their 90s by now |
| 23:51 | <zewt> | where the parser originally came from is academic (and probably very complicated) |
| 23:52 | <caitp> | and it wouldn't be polite to bother a 90 year old enjoying their retirement in florida |
| 23:52 | <Hixie> | more like early 40s... it was only 20 years ago |
| 23:53 | <caitp> | I have a tendency to exaggerate, Hixie :) |
| 23:55 | <caitp> | but, I don't think I'm going to find them to ask why they decided to re-arrange authored content --- however I've read things by other people who have had similar critiques (and yes, a lot of them were xml people) |
| 23:56 | <Hixie> | i doubt they did it very consciously |
| 23:57 | <Hixie> | though the guy who thrust <i><b></i></b> on us is, iirc, cwilso_____ |
