| 03:31 | <zewt> | those small, dubious bits of fame |
| 04:05 | <zewt> | sort of amazing how libjpeg is one of the most reliable libraries in existence, with such a terrible api |
| 04:06 | <zewt> | i guess the fact that if you misuse it, it tends to implode immediately instead of subtly six months later helps |
| 04:11 | <MikeSmith> | cabanier: do you have any idea of what the intent of the following change was? |
| 04:11 | <MikeSmith> | cabanier: https://github.com/w3c/html/commit/22b565f08ca451729d845cd39997b65585d06732 |
| 04:12 | <MikeSmith> | cabanier: I realize you didn't make the change. Jay did. I'm just trying to figure out what his goal was. |
| 04:12 | <cabanier> | MikeSmith: yes. This clarifies the behavior of createPattern and makes the normative text match the box above |
| 04:12 | <cabanier> | MikeSmith: It also makes it match the whatwg spec |
| 04:12 | <MikeSmith> | cabanier: OK |
| 04:13 | <MikeSmith> | cabanier: I ask because I'm trying to get the document ready for publication, and it's failing validation because Jay introduced a markup error when he made the change. |
| 04:14 | <cabanier> | MikeSmith: the webkit bug to make this work on webkit is here: https://bugs.webkit.org/show_bug.cgi?id=132407 |
| 04:14 | <cabanier> | MikeSmith: ah |
| 04:14 | <cabanier> | MikeSmith: anything I can do? |
| 04:15 | <MikeSmith> | cabanier: nah I can fix it myself I guess, assuming that the stuff at https://github.com/w3c/html/commit/22b565f08ca451729d845cd39997b65585d06732#diff-36cd38f49b9afa08222c0dc9ebfe35ebR42788 is a mistake |
| 04:16 | <MikeSmith> | I can't see what else it would be |
| 04:16 | <cabanier> | MikeSmith: it looks like a mistake |
| 04:17 | <MikeSmith> | cabanier: ok |
| 04:41 | <MikeSmith> | cabanier: btw it seems that change was only made on the html5_canvas_CR branch, right? |
| 04:41 | <cabanier> | MikeSmith: likely |
| 04:42 | <MikeSmith> | ok |
| 04:42 | <MikeSmith> | cabanier: it doesn't need to be made on the nightly branch? |
| 04:43 | <cabanier> | MikeSmith: it should but we haven't brought everything over yet |
| 04:43 | <MikeSmith> | ok |
| 04:43 | <cabanier> | MikeSmith: once level 1 is CR, we can do level 2 in earnest |
| 04:44 | <MikeSmith> | I see |
| 04:44 | <cabanier> | MikeSmith: move over all changes, start stripping unimplemented features, etc |
| 04:48 | <MikeSmith> | yeah |
| 06:02 | <MikeSmith> | cabanier: so I've spent an hour and half now dealing with fixes to get canvas CR document to pass pubrules, despite having been told the document was "ready to go" |
| 06:35 | <cabanier> | MikeSmith: did Jay not run them? |
| 06:35 | <cabanier> | I guess he didn't |
| 06:35 | <cabanier> | MikeSmith: sorry about that! |
| 06:40 | <dbaron> | hrmmmm |
| 06:40 | <MikeSmith> | cabanier: Jay doesn't seem to be able to figure out the build steps. The build setup is baraque and unclear to me also but the way I figure it out is by looking at the code for the python scripts the build uses. |
| 06:41 | <dbaron> | bounces of emails that are rejected by the whatwg list come from the exact same envelope sender as messages *on* the list, and thus they get filtered in my mail setup to the folder with the list mail... and thus I miss the fact that my messages to the whatwg list are all being rejected for being GPG-signed |
| 06:42 | <MikeSmith> | cabanier: I would think that anybody else who had any experience dealing with headaches of trying to use an arcane build process that somebody else made would do the work of going through the same process that I'm doing right now. |
| 06:42 | <MikeSmith> | cabanier: instead, I have to do it. Because Jay apparently just kind of threw his hands up and gave up. |
| 06:43 | <MikeSmith> | cabanier: Which I don't mind really except that his name is on the document as the editor who's responsible for it. |
| 06:43 | <MikeSmith> | cabanier: or one on the names |
| 06:43 | <MikeSmith> | cabanier: frankly I really can't figure out what value the rest of the canvas editors are adding here |
| 06:44 | <MikeSmith> | cabanier: but I would like at a minimum that they first do no harm |
| 06:44 | <MikeSmith> | cabanier: so that I don't have a spend hours cleaning after their bungling |
| 06:45 | <MikeSmith> | cabanier: seriously I would really prefer that you be the single editor of the W3C document and the others just please get out of the way |
| 06:49 | <MikeSmith> | dbaron: can't speak to the envelope-sender problem but I vaguely recall that when I sent GPG-signed messages to the whatwg list before, I had to do them in the inline-signing way instead of with the signature as an attachment |
| 07:02 | <SamB> | MikeSmith: eww! |
| 07:22 | <MikeSmith> | is heading::after { content: leader(dotted) } |
| 07:22 | <MikeSmith> | ... currently valid in CSS? |
| 07:23 | <MikeSmith> | or content: leader(". ") |
| 07:46 | <krit> | zcorpan: Hi. Do you travel to Seoul? |
| 07:47 | <zcorpan> | krit: yep |
| 07:48 | <krit> | zcorpan: cool, want to ask for FPWD of Geometry Interface there |
| 07:48 | <Ms2ger> | You know you can just send that to the list too, right? |
| 07:48 | <zcorpan> | krit: i don't mind FPWDing it |
| 07:49 | <krit> | Ms2ger: I need to do it anyway. Just want to check if the other editors are fine with the next step :) |
| 07:57 | <foolip> | Hixie: I haven't created a bug for the XHTML <input> bug, I discovered it while writing that comment. when cloning the content attribute is copied and the IDL attribute is set to true |
| 09:31 | <annevk> | ffffuuuu |
| 09:31 | <annevk> | Domenic_: http://www.w3.org/TR/media-source/#mediasource new list objects and methods to manipulate them that aren't even on the list objects... |
| 09:33 | <annevk> | Hixie: you might want to take a look at that API too o_O |
| 09:35 | <MikeSmith> | annevk: I been saying for a while that I wish you guys would be looking at the MSE spec carefully. I see now that kinetik sent an intent message for it |
| 09:36 | <MikeSmith> | anyway I guess I could have made more noise about it |
| 09:36 | <annevk> | MikeSmith: I thought we convinced them to stop using createObjectURL() |
| 09:37 | <MikeSmith> | annevk: I thought they should be able to to realize that by themselves |
| 09:37 | <MikeSmith> | didn't even realize that was still in there |
| 09:37 | <annevk> | MikeSmith: there's too much uninformed people writing specs; W3C shouldn't accept anyone willing without giving them proper guidance |
| 09:37 | <MikeSmith> | well yeah |
| 09:38 | <MikeSmith> | but the decisions about editors should be made by WGs |
| 09:38 | <MikeSmith> | and the chairs of WGs |
| 09:39 | <annevk> | sure, but there's Team people assigned to WGs too |
| 09:39 | <MikeSmith> | and that requires compentency and discernment on the part of chairs |
| 09:39 | <MikeSmith> | annevk: true |
| 09:40 | <MikeSmith> | if the decisions were mine we'd have quite a few less editors |
| 09:41 | <annevk> | there's that too, assigning multiple editors to a single specification is asking for trouble |
| 09:41 | <MikeSmith> | sometimes there are good reasons for it |
| 09:41 | <MikeSmith> | but many times there aren't |
| 09:42 | <annevk> | but editors not keeping track of IDL discussions is really problematic when it's all still being figured out |
| 09:42 | <MikeSmith> | annevk: that spec predates some of the recent discussions |
| 09:43 | <MikeSmith> | it's already been implemented and shipped and it's being used in production |
| 09:43 | <annevk> | in Chrome and IE? |
| 09:43 | <MikeSmith> | the time to scrutinize it carefully was last year, or before |
| 09:43 | <MikeSmith> | annevk: yeah |
| 09:43 | <annevk> | oh |
| 09:43 | <annevk> | bah |
| 09:43 | <MikeSmith> | Netflix is using it, others are too |
| 09:48 | <MikeSmith> | annevk: anyway I take your point about the W3C team needing to assert more responsibility over not just accepting anybody as editors just because they're willing |
| 09:48 | <MikeSmith> | the "giving them proper guidance" part is the hard part |
| 09:48 | <MikeSmith> | so fail to adhere to guidance even after it's given |
| 09:49 | <MikeSmith> | but aside from that it seems like the spec reviews the TAG has been providing have helped |
| 09:49 | <annevk> | If Jeff wants to continue to make the point that the W3C needs staff, they better do something |
| 09:49 | <annevk> | Yeah a bit |
| 09:50 | <MikeSmith> | annevk: I have yet to see any editors respond outright negatively to any specific changes requested in TAG review |
| 09:51 | <MikeSmith> | it seems like they pretty much have been very glad to have the review |
| 09:51 | <annevk> | It's more that the TAG hasn't done much review |
| 09:54 | <MikeSmith> | annevk: I guess they should do more then |
| 09:56 | <MikeSmith> | as fun as it is to hate on authority, I guess sometimes having an authority to answer to helps keep people honest |
| 09:57 | <MikeSmith> | I mean it's a lot harder for some editor or WG to just blow off comments from the TAG than it is for the editor or WG to do that to an individual reviewer |
| 09:57 | <annevk> | Which is fucked |
| 09:57 | <MikeSmith> | sure |
| 09:58 | <MikeSmith> | it's fucked that WGs can blow off comments without consequences |
| 09:58 | <annevk> | E.g. I think http://annevankesteren.nl/2011/01/wai-aria-objection is still unresolved |
| 09:59 | <MikeSmith> | but again the main responsibility there is supposed to be on the chairs to act in good faith and make sure that all comments are either resolved to satisfaction or brought the Director's attention |
| 10:00 | <MikeSmith> | annevk: yeah in that case during the transition call they actively misrepresented the status of your comment |
| 10:00 | <MikeSmith> | as far as I can see |
| 10:00 | <annevk> | Would not surprise me |
| 10:01 | <annevk> | MikeSmith: btw, if that MediaSource thing is implemented, how does the Stream thing work that's mentioned in the draft? |
| 10:01 | <annevk> | MikeSmith: I guess that bit isn't implemented? |
| 10:02 | <MikeSmith> | dunno but yeah I'd guess that part may not be in the implementations |
| 11:14 | <annevk> | Why the fuck does Firefox still prompt for this? http://dump.testsuite.org/xhr/upload-redirect.html |
| 11:17 | <annevk> | smaug____: can you explain why in that URL there's no progress event before the prompt? |
| 11:23 | <smaug____> | hmm |
| 11:25 | <annevk> | also, the prompt needs to die, just commented on the bug that sicking filed ages ago |
| 11:26 | <smaug____> | ah, upload progress |
| 11:26 | <smaug____> | why would there be upload progress before the prompt ? |
| 11:29 | <smaug____> | redirect, then you upload the data |
| 11:29 | <annevk> | smaug____: how do you know there's a redirect? |
| 11:30 | <annevk> | smaug____: data is part of the request, redirect is the response |
| 11:31 | <smaug____> | redirect is part of request too |
| 11:31 | <smaug____> | no |
| 11:31 | <smaug____> | ? |
| 11:32 | <annevk> | no |
| 11:32 | <annevk> | -> lunch |
| 11:32 | <smaug____> | well, it is |
| 11:32 | <smaug____> | since there is the other connection to the redirected url |
| 11:37 | <smaug____> | annevk: what happens if you send some more data and redirect |
| 11:40 | <zcorpan> | jgraham: could critic be less silent about tracking breaking? maybe it could add a new comment in the PR? |
| 11:42 | <jgraham> | zcorpan: It's very noisy to me :) |
| 11:43 | <jgraham> | eah. I think with a bit of work I could maybe make it try to rebase automatically. But I'm not sure |
| 11:47 | <zcorpan> | yeah best would be if it figured things out and tracking wouldn't break of course :-) |
| 11:48 | <smaug____> | annevk: but redirects are interesting from progress events point of view |
| 12:13 | <annevk> | smaug____: yes they are |
| 12:13 | <annevk> | smaug____: I'm trying to figure out https://bugzilla.mozilla.org/show_bug.cgi?id=882458 |
| 12:14 | <annevk> | smaug____: which adds CORS to the mix |
| 12:14 | <smaug____> | annevk: anyhow, I think it is some timing issue that redirect handling gets handled before some queued upload notifications. |
| 12:14 | <smaug____> | annevk: so uploading some huge data might give different results |
| 12:14 | <smaug____> | for the prompt case |
| 12:18 | <smaug____> | annevk: per spec what should happen to the upload progress events in case of redirect |
| 12:20 | <annevk> | smaug____: I think what we do is correct |
| 12:21 | <annevk> | smaug____: redirects should not be observable from the page as they happen |
| 12:21 | <annevk> | smaug____: apart from the prompt, we shouldn't prompt |
| 12:21 | <smaug____> | well, XHR case |
| 12:22 | <smaug____> | perhaps the API user would like to know |
| 12:22 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24375 we can't reveal much about redirects |
| 12:24 | <smaug____> | don't browsers change POST to GET in case of certain 30x responses |
| 12:24 | <smaug____> | what happens to the data |
| 12:25 | <annevk> | smaug____: it won't be included in the subsequent request |
| 12:26 | <annevk> | smaug____: that can probably use some clarification in the Fetch Standard I suspect |
| 12:26 | <smaug____> | annevk: yet responseURL url points to the final url, which might have got the data after all |
| 12:28 | <annevk> | smaug____: no |
| 12:28 | <smaug____> | wait, what |
| 12:28 | <annevk> | smaug____: you do a request with a body attached; you get a response that redirects and degrades to GET; you do another request to the new URL without body attached; you get a response |
| 12:28 | <smaug____> | responseURL is what? |
| 12:29 | <annevk> | responseURL will point to the new URL |
| 12:29 | <smaug____> | exactly |
| 12:29 | <annevk> | how would it get the data? |
| 12:29 | <smaug____> | the final url |
| 12:29 | <annevk> | it's only included in the first request |
| 12:29 | <smaug____> | er, oops |
| 12:29 | <smaug____> | s/ might have got the data after all/ might not have got the data after all/ |
| 12:29 | <annevk> | ah |
| 12:29 | <smaug____> | so that is odd API |
| 12:30 | <smaug____> | you thought you sent data somewhere |
| 12:30 | <annevk> | and you did |
| 12:30 | <smaug____> | and you think you know where it went... |
| 12:30 | <annevk> | so yes, you can't figure out if the data was sent several times or not |
| 12:30 | <annevk> | I didn't design HTTP... |
| 12:31 | <smaug____> | yup |
| 12:31 | <smaug____> | yeah, this is just silly, but ok |
| 12:31 | <smaug____> | annevk: could you still test post with large upload data |
| 12:32 | <smaug____> | browser does know where it uploaded the data, so perhaps XHR should tell that |
| 12:32 | <annevk> | we could maybe expose redirect response codes |
| 12:33 | <annevk> | redirectStatuses = ["307", "308"] |
| 12:34 | <annevk> | then you'd know your request body was uploaded thrice |
| 13:24 | <MikeSmith> | annevk: if you have some time, can you please look https://github.com/w3c/web-platform-tests/pull/959 from caitp (changes to test for for the XHR spec) |
| 13:24 | <MikeSmith> | these commits: https://github.com/caitp/web-platform-tests/commit/e0b1ae96b20fe2df95fc339e74e98d341ab2c28e & https://github.com/caitp/web-platform-tests/commit/3adde96454f633bdf537e13b18c70b5ff17e11ac |
| 13:26 | <MikeSmith> | related to https://github.com/w3c/web-platform-tests/issues/958 |
| 13:28 | <MikeSmith> | apparently Hallvord made a test change a while back to match some change that had been made to the spec |
| 13:29 | <MikeSmith> | and/or I guess I could also ask Hallvord to look at it |
| 13:30 | <annevk> | MikeSmith: better ask hallvors, but I added some comments |
| 13:30 | <MikeSmith> | oh thanks |
| 13:30 | <annevk> | MikeSmith: second change seems wrong at least |
| 13:30 | <MikeSmith> | just sawa your comments |
| 13:30 | <MikeSmith> | I'll ping Hallvord too |
| 13:30 | <caitp> | the second change is not wrong, I commented explaining why |
| 13:30 | <annevk> | yes it is |
| 13:31 | <annevk> | events can be dispatched synchronously and they're |
| 13:31 | <caitp> | if a browser complies with the spec exactly, then UNSENT will never be set before the event is dispatched |
| 13:31 | <annevk> | there's nothing in the spec that says a task is queued |
| 13:31 | <annevk> | correct |
| 13:31 | <annevk> | but the events are not dispatched from a queue |
| 13:31 | <caitp> | and therefore, asserting that the readyState is UNSENT during the event listener will never assert correctly |
| 13:33 | <annevk> | oh wait, I guess I should have looked at more context |
| 13:34 | <annevk> | caitp: sorry, my bad |
| 13:35 | <annevk> | caitp: looking at https://github.com/caitp/web-platform-tests/blob/master/XMLHttpRequest/abort-event-order.htm it seems better to move the "state should be UNSENT" check to where xhr.abort() is called |
| 13:35 | <jtcranmer> | new URL("http://" + domain) should fail if ToASCII fails, right? |
| 13:35 | <annevk> | jtcranmer: yes |
| 13:35 | jtcranmer | glares at Firefox |
| 13:35 | <caitp> | I can't remember if that test uses a synchronous request or not |
| 13:35 | <caitp> | but I agree, a timeout isn't ideal |
| 13:36 | <annevk> | caitp: if it was sync you wouldn't be able to invoke abort() |
| 13:36 | <caitp> | yeah |
| 13:37 | <caitp> | right, I see what you mean |
| 13:41 | <caitp> | i suppose testharness.js doesn't have a way to say "expect N assertions during this test" or something, does it? |
| 13:47 | <zewt> | sounds like a headache ("which assertion is missing?") |
| 13:49 | <caitp> | well, potentially |
| 13:49 | <caitp> | I prefer it to var someAsyncPathWasReached = false; and asserting it is true at some point to be sure it was called, though |
| 13:50 | <caitp> | or, somePathWasReached* |
| 13:50 | <MikeSmith> | caitp: testharness.js doesn't provide any way to do that afaik |
| 13:51 | <MikeSmith> | if it has a way jgraham would know |
| 13:51 | <caitp> | I was just looking through it and it doesn't record the number of assertions called |
| 13:51 | <MikeSmith> | right |
| 13:51 | <MikeSmith> | wait though |
| 13:52 | <MikeSmith> | it's possible to report the number of assertions after the test has run |
| 13:54 | <caitp> | maybe with steps.length? |
| 13:57 | <jtcranmer> | annevk: would you say it's safe to implement URL.domainTo* right now? |
| 13:59 | <odinho> | caitp: sometimes having a results array where you push stuff like "upgradeneeded", "success" etc is a nice way imho. Then you get both ordering, not any extras (as long as you add to results even on unexpected events) and clear errors and docs. |
| 13:59 | <annevk> | jtcranmer: yeah |
| 14:00 | <annevk> | jtcranmer: I can remove the note |
| 14:00 | <annevk> | jtcranmer: with everyone roughly agreeing on UTS #46 I think we're done |
| 14:00 | <jtcranmer> | I think that'll be easier to get implemented in Firefox than trying to make new URL("") properly handle punycode |
| 14:00 | <annevk> | jtcranmer: well... we should really fix both |
| 14:00 | <annevk> | jtcranmer: they both hook into the same underlying concept |
| 14:01 | <annevk> | jtcranmer: so please file bugs |
| 14:01 | <jtcranmer> | annevk: yes, but in terms of implementation details :-) |
| 14:01 | <jtcranmer> | annevk: oh, were you going to add some sort of notion of displayable Unicode variants for the homograph attack issue |
| 14:01 | <annevk> | caitp: any reason you can't move VerifyResult to after xhr.abort() ? |
| 14:02 | <annevk> | caitp: xhr.abort() puts the whole synchronously in the can so that seems fine |
| 14:02 | <annevk> | whole thing* |
| 14:02 | <caitp> | that would probably be okay |
| 14:02 | <annevk> | jtcranmer: my idea was to add domainToUI() for to match what the UI does |
| 14:03 | <jtcranmer> | okay |
| 14:03 | <caitp> | kind of weird to submit another CL for that test right after the other one was merged though :p but I can see how that would benefit non-compliant browsers better |
| 14:06 | <annevk> | oh hallvors just merged it :/ |
| 14:06 | <annevk> | he shouldn't have merged that |
| 14:06 | <annevk> | oh well |
| 14:06 | <annevk> | it's mostly because it would be a lot better to not have setTimeout there |
| 14:06 | <caitp> | yeah, I'll send another one, I just want to make sure it passes first |
| 14:07 | <caitp> | well, nightly fails it :> |
| 14:17 | <annevk> | jtcranmer: if you're going to implement and want toUI letting me know would be good |
| 14:17 | <annevk> | jtcranmer: please cc me on those bugs |
| 14:17 | <jtcranmer> | annevk: I'm thinking about implementing |
| 14:18 | <annevk> | jtcranmer: if you need spec updates ping me as well, I try to prioritize stuff that gets implemented |
| 14:19 | <jtcranmer> | annevk: it's more like "I need this feature for my own content code and the suckiness of new URL in Firefox killed my idea for a polyfill" |
| 14:19 | <annevk> | jtcranmer: you might get baku to fix new URL, but maybe not |
| 14:20 | <jtcranmer> | annevk: I know from some experience that there might be a slight internal compat issue with nsURL |
| 14:24 | <jtcranmer> | annevk: filed and CC'd |
| 14:29 | <annevk> | jtcranmer: ta |
| 14:29 | <annevk> | where is smaug? |
| 14:29 | <annevk> | anyway, he was correct, http://dump.testsuite.org/xhr/upload-redirect.html now tests a largish blob |
| 14:54 | <IZh> | What is the time zone of Ben Schwarz? |
| 14:59 | <annevk> | IZh: Australian iirc |
| 14:59 | <IZh> | annevk: Thanks. |
| 15:47 | <smaug____> | annevk: ping |
| 15:47 | <annevk> | smaug____: http://www.nohello.com/ |
| 15:47 | <smaug____> | while xhr is being processed, the value of responseURL may change, right? |
| 15:48 | <smaug____> | ping is not hi |
| 15:48 | <smaug____> | except based on nohello |
| 15:48 | smaug____ | doesn't like nohello |
| 15:49 | <annevk> | smaug____: responseURL is either "" or the URL |
| 15:49 | <smaug____> | annevk: right, say before redirection it has some value, and after that something else |
| 15:49 | <smaug____> | it is not something for the final url only |
| 15:49 | <annevk> | smaug____: no, redirects are not exposed |
| 15:50 | <smaug____> | hmm |
| 15:50 | <annevk> | smaug____: they are atomic |
| 15:50 | <smaug____> | the spec is hard to read these days |
| 15:50 | <annevk> | smaug____: you made that comment before, I can't do much with that |
| 15:51 | <jgraham> | smaug____: The point is that you could have compressed "ping"; (ack); (question); (answer) into (question); (answer) and saved a rtt |
| 15:51 | <smaug____> | the spec says "An XMLHttpRequest has an associated response" |
| 15:52 | <jgraham> | The Mozilla habit of doing "ping" rather than just saying something is pretty annoying |
| 15:52 | <smaug____> | but it doesn't seem to say that response thing is actually defined in Fetch |
| 15:53 | <smaug____> | annevk: so what in the spec says redirects aren't exposed |
| 15:59 | <annevk> | smaug____: Fetch follows redirects before returning a response |
| 15:59 | <smaug____> | hmm |
| 16:00 | <smaug____> | ok, so in which state should XHR be in order to return non-empty responseURL |
| 16:00 | <annevk> | smaug____: HEADERS_RECEIVED |
| 16:04 | <smaug____> | ok, thanks |
| 16:04 | <smaug____> | r- for the responseURL patch then |
| 16:07 | <annevk> | smaug____: the way to read the spec is that response is a network error, whose url is null |
| 16:07 | <smaug____> | that is one thing which is surprising |
| 16:07 | <annevk> | smaug____: we update response for the first time when we change the state to HEADERS_RECEIVED, using the "process response" callback from the network layer |
| 16:07 | <smaug____> | that response is in error state even before anything has happened |
| 16:08 | <smaug____> | some uninitialized state might make it easier to read |
| 16:08 | <annevk> | smaug____: it's kind of convenient since it fills in a bunch of attributes by default |
| 16:08 | <annevk> | smaug____: but I could do that and have if/else all over too I suppose |
| 16:08 | <annevk> | more text :( |
| 16:09 | <smaug____> | sure, but no need to optimize the pseudo code spec has here, IMO |
| 16:09 | <smaug____> | that pseudo code isn't after all compiled to binary |
| 16:09 | <annevk> | smaug____: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25589 |
| 16:10 | <smaug____> | thanks |
| 17:26 | <Hixie> | dbaron: what's the mime type i should allow? |
| 17:27 | <dbaron> | Hixie, multipart/signed, perhaps? Though I think I've fixed my setup so it doesn't sign messages To or Cc to whatwg@{lists.,}whatwg.org |
| 17:28 | <dbaron> | (I forgot about Cc and lists.whatwg.org the last time I did that.) |
| 17:29 | <Hixie> | i've added multipart/signed to the list |
| 18:09 | <cwilso_____> | hixie: yes, you do recall correctly that I'm personally responsible for overlapping <b> and <i> tags. |
| 18:11 | SamB | tries to remember if those actually appeared in an ICFP contest, or if that demanded a more well-formed markup ... |
| 18:21 | <Hixie> | MikeSmith: i just got some 504s from Firefox on Bugzilla, so i guess it's not Chrome's fault |
| 20:02 | <caitp> | I'm trying to find where, in http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html or possibly http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html, it would say that a user agent should not scroll to a fragment identifier if the fragment identifier is already in the frame's location |
| 20:03 | <caitp> | what might be a better place to look for that, because I'm not seeing anything which would result in that behaviour |
| 20:04 | <caitp> | (gecko, blink and safari all seem to share that behaviour, so I assume it's in there somewhere, and it probably shouldn't be) |
| 20:04 | <caitp> | s/safari/webkit |
| 20:04 | <SamB> | caitp: hmm? |
| 20:05 | <SamB> | got a page to show what you mean? |
| 20:05 | <caitp> | hang on, I'll get an example |
| 20:06 | <caitp> | https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md -> click on the code of conduct link, which will navigate to the #coc fragment |
| 20:06 | <caitp> | then scroll up and click on it again |
| 20:16 | <zewt> | (a "contributing" page that starts out with "code of conduct" sure makes me not want to contribute) |
| 20:18 | <caitp> | well, you're welcome to not contribute if you wish ^_^ |
| 20:19 | <SamB> | maybe steal linux.git's thing |
| 20:19 | <SamB> | "certificate of origin", was it? |
| 20:20 | <caitp> | the discussion is really about navigating to fragment identifiers, and not about CoCs :p It's just an example |
| 20:21 | <SamB> | hmm, that example seems to (unaccountably) require JS ... at least, it's not working with the scripts blocked ... |
| 20:21 | <caitp> | really |
| 20:23 | <caitp> | hmm, maybe I can make a simple example in pure html real quick |
| 20:25 | <caitp> | huh, you're right, it does seem to be a js thing |
| 20:26 | <caitp> | well, that's kind of a relief at least |
| 20:26 | <SamB> | I wasn't sure if the strangeness was from JS or not, but the ToC link didn't even seem to work without it |
| 20:28 | <caitp> | yeah, that's kind of a relief |
| 21:01 | <Hixie> | does arabic use the same baseline as roman/latin scripts? |
| 21:07 | <SamB> | hmm, Type1 spec doesn't seem to cover metrics ... |
| 21:10 | SamB | finds http://www.newyorker.com/online/blogs/books/2011/06/where-latin-and-arabic-meet-a-bridging-of-two-alphabets.html when he googles ... |
| 21:12 | <Hixie> | yeah i didn't find anything useful doing tons of google searches on the subject, weirdly |
| 21:22 | <SamB> | Hixie: I'm going to go with a "it looks like they sure can", because that lady *seems* to use the same baseline for both from what I can see of the pictures there ... |
| 21:22 | <SamB> | oh maybe I should check the index of TAOCP |
| 21:23 | <astearns_> | Hixie: this image from rishida suggests that Arabic uses an alphabetic baseline http://rishida.net/docs/unicode-tutorial/part6#baseline |
| 21:23 | <Hixie> | astearns_: thanks, that does seem pretty clear |
| 21:24 | <Hixie> | SamB: the problem is that any individual picture will make it look like all letters in all scripts use the same baseline because unless you're doing ugly things with the font size, they'll always be roughly aligned |
| 21:24 | <astearns_> | how it uses the baseline is pretty different in calligraphic Arabic |
| 21:24 | <Hixie> | oh? |
| 21:24 | <astearns_> | a curved or slanted baseline for a group of characters must touch the baseline |
| 21:24 | <astearns_> | but only at one point |
| 21:25 | <astearns_> | s/touch the baseline/touch the straight baseline/ |
| 21:25 | <Hixie> | i'm going to pretend i didn't hear that |
| 21:25 | <Hixie> | la la la |
| 21:26 | <SamB> | astearns_: I'm going to assume computer typography isn't ready to produce this automatically in any case |
| 21:27 | <SamB> | obviously the people who first try to do that in a browser will have a lot of room to experiment ... |
| 21:27 | <astearns_> | SamB: I found docs for a software package that does it right as I was googling |
| 21:27 | <SamB> | oh? |
| 21:27 | <astearns_> | gah, now I have to find it again :) |
| 21:28 | <SamB> | I guess, more to the point, WEB BROWSERS suck at straight-line typography as it is |
| 21:28 | <astearns_> | SamB: ah, an old, no longer maintained package: http://freetype.org/opentype/index.html |
| 21:28 | <SamB> | hah |
| 21:28 | <astearns_> | so the next question is whether harfbuzz handles it |
| 21:29 | <SamB> | oh wait that's a package name? |
| 21:29 | <SamB> | I thought it was the font format's name |
| 21:29 | <SamB> | ah, freetype *1* |
| 21:29 | <SamB> | that wasn't in the URL |
| 21:30 | <SamB> | astearns_: anyway, presumably hixie was talking about the flat one |
| 21:31 | <SamB> | I still think harfbuzz is a strange name for a package ... |
| 21:49 | <caitp> | the idlharness test failures in wpt are really, really hard to understand :( |
| 21:52 | <zewt> | okay, websocket "masking" needs to be shot into the sun |
| 21:53 | <MikeSmith> | Hixie: hard to troubleshoot the 504s since so far the systems team has told me they find nothing strange in the logs on the server side |
| 21:53 | <Hixie> | MikeSmith: yeah |
| 21:53 | <Hixie> | MikeSmith: dunno what could be causing it |
| 21:53 | <Hixie> | MikeSmith: earlier today bugzilla was being REALLY slow, lots of 504s in both firefox and chrome |
| 21:53 | <Hixie> | it's a bit better now |
| 21:55 | <MikeSmith> | Hixie: I'll ask them to check again |
| 22:09 | <MikeSmith> | Hixie: "that was due to some DB maintenance earlier, shouldn't be an ongoing thing", I'm told |
| 22:09 | <MikeSmith> | as far as the 504s earlier today |
| 22:13 | <zewt> | is there somebody specific i can hate for the tcp thing where I randomly have to sit around and twiddle my thumbs for a couple minutes unless I figure out how to set SO_REUSEADDR |
| 22:13 | <Hixie> | MikeSmith: k |
| 22:14 | <Hixie> | zewt: oh man, the unix sockets api. |
| 22:14 | <Hixie> | what a pain. |
| 22:14 | <zewt> | well it's the kernel socket layer causing the problem, not the api itself |
| 22:14 | <zewt> | but yeah, heh |
| 22:15 | <Hixie> | in other twiddling news, i twiddled the spec style sheet again |
| 22:15 | <Hixie> | hope y'all don't lose your collective minds again :-P |
| 22:18 | <Hixie> | man, @scope is simultaneously awesome in its coolness and power, and frightening in its implications on the cascade |
| 22:19 | <Hixie> | i hope we've staffed up the support lines for more specificity/cascade confusion. :-) |
| 22:19 | <Hixie> | TabAtkins: ^ |
| 22:19 | <TabAtkins> | Yeah, we might drop it. |
| 22:19 | <TabAtkins> | The cascade implications are confusing. |
| 22:19 | <TabAtkins> | And the optimizations we might want to do to scoped styles are less good if they're overused. |
| 22:19 | <TabAtkins> | Just doing nesting is probably better. |
| 22:20 | <zewt> | what's confusing, when you can open the inspector and see the css rules applying to an element and their order? |
| 22:23 | <Hixie> | TabAtkins: is @global something anyone cares about, or should i just drop that? |
| 22:24 | <SamB> | Hixie: well, define "cares about" |
| 22:25 | <Hixie> | that anyone will implement |
| 22:25 | <SamB> | because I'd kind of prefer were required NOT to implement that, personally ... |
| 22:25 | <SamB> | +it |
| 22:26 | <Hixie> | k well nobody seems to have championed it so i guess i'll drop it |
| 22:38 | <zewt> | remind me what @global is? |
| 22:38 | <zewt> | escape from @scope? |
| 22:38 | <SamB> | zewt: that's the thing I don't want to exist, certainly |
| 22:39 | <SamB> | zewt: or from <style scoped>, no? |
| 22:39 | <zewt> | i don't know what the use cases are, but it seems nice to be able to know for sure that if you insert a DOM tree inside a scoped stylesheet, it's not capable of breaking out of that and affecting other things (intentionally or not) |
| 22:40 | <SamB> | zewt: actually I think it' |
| 22:40 | <zewt> | but i'm assuming i know what we're talking about when I probably don't |
| 22:40 | <SamB> | er, that is, it's still possible to get out of the box, I think |
| 22:41 | <SamB> | possibly you'd need a particular attribute along with the <style scoped> |
| 22:41 | <zewt> | font-face, etc. are still scoped, right? (i remember some suggestions for font-face to not be scoped, which seemed like a terrible idea) |
| 22:41 | <SamB> | Hixie: hmm, so what is supposed to happen if a <style> without <scoped> appears in the body anyway? |
| 22:42 | <SamB> | zewt: you mean @font-face ? |
| 22:42 | <zewt> | yeah |
| 22:42 | <Hixie> | zewt: yeah, it was the escape mechanism |
| 22:42 | <Hixie> | SamB: same as if it's in the head |
| 22:42 | <SamB> | presumably instead of making that not-scoped, browsers should just, you know, hash-cons them ... |
| 22:42 | <Hixie> | SamB: (but it's invalid) |
| 22:43 | <Hixie> | @font-face and company aren't scoped, which seems terrible to me |
| 22:43 | <Hixie> | same with counter styles, etc |
| 22:43 | <SamB> | Hixie: Ah. It seems like the spec very carefully doesn't actually SAY that it should act that way. |
| 22:43 | <zewt> | yuck, they definitely need to be scoped |
| 22:43 | <Hixie> | SamB: really? |
| 22:44 | <SamB> | hmm, well, that's what I remember thinking anyway |
| 22:44 | <SamB> | my memory is terrible though |
| 22:44 | <Hixie> | heh |
| 22:44 | Hixie | just uses the spec as his memory :-) |
| 22:46 | <zewt> | do you remember why they were made non-scoped? (wondering if there's any point to filing a bug to reopen that conversation) |
| 22:46 | <SamB> | I think it would be better to ban them in scopes for now ... |
| 22:46 | <zewt> | i guess i could find out for myself, i think i was in that thread |
| 22:46 | <zewt> | they should just be scoped like anything else |
| 22:46 | <SamB> | (if it's because it's too hard to implement them scoped properly) |
| 22:47 | <Hixie> | zewt: it turns out to not be obvious what it means to scope them |
| 22:47 | <SamB> | so, um, ban them until it becomes obvious? |
| 22:47 | <zewt> | it seems obvious from the author's perspective, anyway, though my mental picture of what scoping stylesheets actually means could be wrong |
| 22:48 | <Hixie> | zewt: like, suppose that an element has the font-family 'foo', and that there's a @font-family rule that sets 'foo'. Now suppose there's a scoped section that introduces a new font called 'foo'. An element in that section has 'font: inherit'. What font should it use? |
| 22:49 | <SamB> | it is reasonably easy to find out what authors would expect: ban it for now and wait for them to show what they wanted to use it for but can't |
| 22:49 | <Hixie> | SamB: yeah, maybe. dunno. not my spec, not my problem. :-) |
| 22:49 | <SamB> | Hixie: so it's a dynamic/lexical scope issue? |
| 22:49 | <Hixie> | it's a cascade/inheritance issue |
| 22:50 | <SamB> | oh right |
| 22:50 | <SamB> | didn't read far enough |
| 22:50 | <SamB> | I was thinking "one of the outer rules references a name that's rebound in the scope, and applies to one of the inner elements" |
| 22:50 | <zewt> | seems like if you're <div><style scoped>xxx</style>yyy</div><div>zzz</div>, yyy should act exactly as though the @scoped attribute wasn't present, and zzz should act as if the <style scoped> node doesn't even exist |
| 22:51 | <SamB> | Hixie: I'd go with inherit the font actually used outside |
| 22:54 | <zewt> | afk |
| 22:56 | <Hixie> | SamB: the issue you raise is another one, yeah |
| 22:56 | <Hixie> | font-family is currently just a bunch of strings, so to make it work as y'all are describing it would need to change to a much more elaborate model |
| 22:56 | <Hixie> | which has huge performance implications |
| 22:57 | <Hixie> | which isn't good for something as core to web rendering as "picking a font" |
| 22:57 | <Hixie> | in other news, https://critic.hoppipolla.co.uk/static-resource/seal-of-approval-left.png is awesome. |
| 22:57 | <SamB> | Hixie: couldn't it just be a list of pointers to font-faces ? |
| 22:58 | <SamB> | but IMO plain ban putting it in @scoped/<style scoped> rather than doing something stupid with it |
| 22:59 | <Hixie> | if it's a list of pointers, then taking getComputedStyle() and sticking it back into style="" would actually chnage the style. |
| 22:59 | <Hixie> | anyway this isn't my spec so i dunno |
| 23:00 | <SamB> | Hixie: oh right |
| 23:15 | <zewt> | Hixie: not sure how it's any worse than css selectors, though |
| 23:15 | <zewt> | where you're doing much more complicated lookups |
| 23:17 | <zewt> | i mean, if it's hard to implement a stack of scoped font-face values efficiently, i'd think a stack of scoped css rules would be far worse |
