| 02:17 | <MikeSmith> | https://whatwebcando.today/ is nice but should track a lot more features |
| 02:35 | <MikeSmith> | yoav: is there an open webkit bug for adding support for <link rel=preload> |
| 04:35 | <yoav> | MikeSmith: I see you opened one |
| 07:01 | <annevk> | So yeah, unsubscribed from public-webapps |
| 07:02 | <annevk> | Guess that era is over |
| 07:03 | <MikeSmith> | annevk: yup |
| 07:03 | <MikeSmith> | for better or worse |
| 07:05 | <MikeSmith> | yoav: yeah, did not find that you or igrigorik_ had opened one yet |
| 07:06 | <yoav> | MikeSmith: Cool. I opened smaller issues as I'm implementing, but always nice to have a meta-issue |
| 07:07 | <tantek> | what happened to public-webapps? |
| 07:08 | <tantek> | just transition wpwg? |
| 07:08 | <annevk> | The bureaucrats took over |
| 07:08 | <tantek> | sigh |
| 07:09 | <annevk> | "being concerned with procedural correctness at the expense of people's needs" is apt in particular as it was called out a few times |
| 07:12 | <tantek> | did any browser implementers respond to the HTML 5.1 CfC for CR? I was busy with conferences at the time and it already closed. https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/thread.html#msg99 |
| 07:15 | <tantek> | If I don't find any I may reply to that thread pointing out that an HTML CfC is meaningless without any browser implementer participation |
| 07:16 | <annevk> | tantek: Microsoft and Yandex |
| 07:16 | <tantek> | I didn't know Yandex made a browser |
| 07:16 | <MikeSmith> | yoav: I actually wasn’t aware you were already implementing it in WebKit |
| 07:17 | <tantek> | annevk: who at Microsoft? |
| 07:17 | <annevk> | tantek: Microsoft edits the fork, Adrian, Travis, Aaron, ... |
| 07:17 | <annevk> | tantek: I don't think they're doing a particularly good job, but they're making changes and copying our work |
| 07:18 | <tantek> | thank annevk. I'll look into it further. |
| 07:18 | <MikeSmith> | yoav: I saw one bug about preload and events but wasn’t sure how it was related (and didn’t look into it further) |
| 07:19 | <MikeSmith> | tantek: the thing is, they already made a bunch of decisions unilaterally without even attempting to ask the WG and record WG decisions |
| 07:19 | <MikeSmith> | as they are supposed to |
| 07:19 | <MikeSmith> | and as they would if they were actuallly sincere about operating by consensus |
| 07:19 | <tantek> | MikeSmith: so it really is off the rails completely then |
| 07:19 | <MikeSmith> | yes |
| 07:19 | <MikeSmith> | bingo |
| 07:20 | <MikeSmith> | they are operating way out of consensus at this point |
| 07:20 | <MikeSmith> | it is just the many people do not even care enough any longer to even bother to speak up |
| 07:21 | <tantek> | this is exactly what I need to be hearing. AB f2f meeting is next week. |
| 07:22 | <MikeSmith> | well at this point I do not know what difference it would make, because they have already decided to operate so far outside of the W3C’s own process |
| 07:23 | <MikeSmith> | they have basically fundamentally de-legitimized everything they are doing |
| 07:23 | <tantek> | in particular this is highly problematic since two WPWG co-chairs are now on the AB, so it is even worse to not be following W3C's own process |
| 07:24 | <MikeSmith> | I am sure they have some ends-justify-the-means rationalization about it |
| 07:24 | <tantek> | that's not going to fly at the AB |
| 07:25 | <MikeSmith> | meanwhile chaals in particular is quietly and unilaterally pulling stunts like this: https://github.com/w3c/html/pull/484/commits/19c383bbce5f032f8e66470d44a95f52f4f0f940 |
| 07:26 | <MikeSmith> | “resetting” the acknowledgements for a document they are hostile-copying against the wishes of the authors who actually created |
| 07:26 | <MikeSmith> | “resetting” the acknowledgements by essentially removing 99% of them |
| 07:27 | <tantek> | that seems quite rude |
| 07:27 | <MikeSmith> | it is gall on top of rudeness motivated by genuine pathology |
| 07:29 | <MikeSmith> | he replaced the real acknowledgements with thanks to a list of people who have had zero to do with this actual document but instead worked on ancient previous versions of HTML specs at the W3C |
| 07:29 | <MikeSmith> | and on XHTML “family” specs |
| 07:31 | <tantek> | that is very odd indeed |
| 07:33 | <MikeSmith> | tantek: in the little bizarro universe he has constructed for himself around this, I am sure it all makes perfect sense to him |
| 07:33 | <MikeSmith> | it is certainly consistent with the rest of the crazy shit he has been doing there |
| 07:34 | <MikeSmith> | loose cannon on personal vendetta as chair of a WG |
| 07:34 | <tantek> | I really do not understand the motivations for these actions. Like why is it worth the personal time to bother with. |
| 07:35 | <MikeSmith> | neurosis |
| 07:35 | <MikeSmith> | is the motivation |
| 07:35 | <MikeSmith> | if not something worse |
| 07:35 | <MikeSmith> | going back years now |
| 07:35 | <tantek> | it just looks petty at this point |
| 07:35 | <MikeSmith> | petty payback time |
| 07:35 | <MikeSmith> | yeah |
| 07:35 | <tantek> | lol |
| 07:36 | <MikeSmith> | sad |
| 07:36 | Ms2ger | waves |
| 07:36 | <tantek> | yeah, I'm off to get breakfast here in London |
| 07:36 | <MikeSmith> | and extra sad that he has managed to take of all of public-webapps down with him |
| 07:36 | Ms2ger | should do likewise |
| 07:36 | <MikeSmith> | hai |
| 07:37 | <Ms2ger> | Chaals on an empty stomach is not something I recommend |
| 07:57 | <ondras> | annevk: why is there only a very small amount of response http headers available to JS for crossorigin requests, even if the request is explicitely allowed via CORS? |
| 08:00 | <Mek> | ondras: you mean why there is a Access-Control-Expose-Headers header? |
| 08:02 | <ondras> | Mek: well I mean why is there https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name |
| 08:03 | <Mek> | ondras: well, that's kind of the same question. That's the list of headers that is available even without explicitly allowing any via the CORS Access-Control-Expose-Headers header |
| 08:04 | <ondras> | Mek: right. so I would like to know why there is a separate way to whitelist headers which somehow duplicates the fact that the response itself -- the body -- was already made available via Access-Control-Allow-Origin |
| 08:04 | <ondras> | Mek: or, in other words, why does one want to hide headers but make the body public |
| 08:11 | <annevk> | ondras: we want explicit consent for both |
| 08:11 | <annevk> | ondras: to avoid exposing debug headers and such |
| 08:17 | <ondras> | annevk: interesting, although I probably do not exactly see the motivation/usecase... the server owner already made the guarantee that the client may process his response data |
| 08:31 | <annevk> | ondras: it just makes it a little trickier to copy-and-paste yourself into a bad situation |
| 08:32 | <annevk> | ondras: a lot of CORS is motivated by that |
| 08:32 | <annevk> | ondras: not really my preference, but so be it |
| 08:33 | <ondras> | okay, thanks |
| 11:15 | <zcorpan> | MikeSmith: i suppose case COMMENT_LESS_THAN_BANG_DASH: should be moved down to |
| 11:15 | <zcorpan> | case COMMENT_END_DASH: |
| 11:15 | <zcorpan> | case COMMENT_START_DASH: |
| 11:15 | <zcorpan> | errEofInComment(); |
| 11:15 | <zcorpan> | /* Emit the comment token. */ |
| 11:15 | <zcorpan> | emitComment(1, 0); |
| 11:49 | <gsnedders> | zcorpan: how convinced are we that this change introduces no behaviour changes? |
| 11:49 | <gsnedders> | zcorpan: modulo parse errors, obviously |
| 11:51 | <zcorpan> | gsnedders: i found one bug in MikeSmith's impl from the tests in the PR, see https://github.com/whatwg/html/pull/1356#issuecomment-225839546 |
| 11:51 | <zcorpan> | gsnedders: but we need to put those tests into html5lib tokenizer tests or something, too |
| 11:51 | gsnedders | is quite worried about unintentional changes here |
| 11:52 | <zcorpan> | gsnedders: yep, that's a risk. please review :-) |
| 11:52 | <gsnedders> | Hard to review every possible transition |
| 11:52 | <zcorpan> | i tried to be as careful as i could be, but i could have made a mistake |
| 11:53 | <gsnedders> | And I don't really want to add parse errors to formal model of the tokenizer to verify this |
| 11:53 | <zcorpan> | doesn't html5lib already test for parse errors in the tokenizer? |
| 11:54 | <gsnedders> | yeah, sure |
| 11:55 | <zcorpan> | https://github.com/whatwg/html/pull/1356#issuecomment-222793570 is intended to cover all relevant cases (except U+0000) |
| 11:55 | <gsnedders> | but proving equivalence modulo parse errors based on an implementation instead of a formal model is virtually impossible |
| 11:56 | <zcorpan> | ah, ok. yeah i suppose i don't have a mathematical proof |
| 11:57 | <gsnedders> | and given we know the current spec is web compat I'm very hestitant about introducing changes to it that we /think/ are right but haven't really tested web compat affect of |
| 12:00 | <zcorpan> | it's 3 new states, there are a finite number of new cases to consider. no? if the parsed tree is the same for those tests, there's no effect for web compat |
| 12:02 | <gsnedders> | yeah, mostly |
| 12:02 | <gsnedders> | still needs a kinda handwavey argument around "current node" though |
| 12:04 | <zcorpan> | what about current node? |
| 12:07 | <gsnedders> | you need to prove it's dead after that state |
| 12:09 | <MikeSmith> | zcorpan: yeah, thanks for catching that (moving the error case for COMMENT_LESS_THAN_BANG_DASH) |
| 12:09 | <MikeSmith> | was just careless there |
| 12:10 | <MikeSmith> | gsnedders: what zcorpan said (about your concern this introduces no behaviour changes) |
| 12:10 | <gsnedders> | MikeSmith: which thing he said? |
| 12:11 | <MikeSmith> | gsnedders: despite that modulo the one flub I made in my implementation, this is extremely low risk |
| 12:12 | <MikeSmith> | it is really only affecting the parse-error behavior, which most implementations do not implement anyway |
| 12:12 | <MikeSmith> | the mistake I made was not because of any lack of clarity in the spec text |
| 12:15 | <MikeSmith> | and no risk of new problems with web compat, because as zcorpan said there is not actually any effect on web compat |
| 12:15 | <MikeSmith> | if you (re)review the whole thing I think you will see that for yourself |
| 14:16 | <MikeSmith> | zcorpan: fixed that tokenizing issue and pushed |
| 14:16 | <MikeSmith> | https://checker.html5.org/parsetree/?parser=html5&content=%3C%21--%3C%21-&submit=Print+Tree |
| 14:16 | <zcorpan> | MikeSmith: yep saw that. writing a comment in the PR :-) |
| 14:18 | <MikeSmith> | k |
| 14:38 | <MikeSmith> | botie, inform zcorpan before merging that PR I wonder if we should try to secure agreement from more implementors for it, or else flag it in the spec with a big editorial note for now |
| 15:50 | <Domenic> | This PR doesn't impact implementers at all, does it? |
| 15:51 | <gsnedders> | Domenic: it *shouldn't*, but we should at least have implementers convinced that changing the state machine as it is in the spec is worth the risk and have them agree that the changes don't have any affect |
| 15:52 | <Domenic> | I don't really agree. I think the editors should be able to make editorial changes and we should be able to trust them to do so. |
| 15:57 | <gsnedders> | I think plenty of us would much rather some parts of the spec, including the parser, be pretty much frozen |
| 16:01 | <MikeSmith> | it does affect those who implement the parse errors and expose them |
| 16:01 | <MikeSmith> | which Henri does for View Source in Firefox |
| 16:02 | <MikeSmith> | and I thought the parse5 implementor was planning to support all the parse errors |
| 16:02 | <MikeSmith> | once we have explicit identifiers for all of them in the spec |
| 16:03 | <gsnedders> | I'll try and work on that over the summer, while I update html5lib to match the spec. |
| 16:04 | <MikeSmith> | fwiw I believe that because this is user-facing change, it should be motivated by trying to do what is best for users |
| 16:04 | <MikeSmith> | and in that regard it is not just editorial |
| 16:05 | <MikeSmith> | certainly it makes a significant difference in the HTML checker behavior |
| 16:05 | <gsnedders> | Now I don't expect it to be totally frozen, but I think we should have a pretty high barrier before changes |
| 16:05 | <MikeSmith> | I behavior change that I assert is a change for the better for users |
| 16:07 | <MikeSmith> | gsnedders: I think another way to look at it is that is maybe the last chance we might still have to get in a change like this before we are really stuck forever with the current legacy suboptimal-for-users behavior |
| 16:08 | <MikeSmith> | let’s try to change it now while we still have some chance |
| 16:09 | <gsnedders> | MikeSmith: why would we not have the chance to make it lateR? |
| 16:26 | <MikeSmith> | gsnedders: because I think the longer we wait to make a change like this, the more likely it is that the answer will be, “Too late to make this kind of change” |
| 17:40 | <MikeSmith> | botie, inform zcorpan before merging that PR I wonder if we should try to secure agreement from more implementors for it, or else flag it in the spec with a big editorial note for now |
| 17:40 | <botie> | will do |