| 06:55 | <tso> | OI STOP BREAKING THE WEB YOU WANKERS |
| 06:56 | <boogyman> | tell us how you really feel |
| 07:09 | <annevk> | So https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c53 is the bug comment I was looking for where Hixie proposed a solution |
| 08:49 | <zcorpan> | anyone with Edge care to check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3887 for me? |
| 08:54 | <annevk> | What is the latest approach to get Edge running on a MacBook? I should probably get on that |
| 09:05 | <annevk> | mathiasbynens: I was wondering if you could help me with an Apache .htaccess question |
| 09:05 | <mathiasbynens> | annevk: I can try |
| 09:06 | <annevk> | mathiasbynens: I have a shared directory for several domains, therein I have an .htaccess that has RewriteCond %{HTTPS} !=on\nRewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] |
| 09:06 | <annevk> | mathiasbynens: now for some domains that have their own rewriterules, this ends up not being executed |
| 09:07 | <annevk> | mathiasbynens: e.g., curl --HEAD http://annevk.nl/test gives a 404 rather than a redirect to the https equivalent |
| 09:07 | <annevk> | mathiasbynens: annevk.nl has RewriteCond %{REQUEST_URI} ^/$\nRewriterule ^(.*)$ https://annevankesteren.nl/ [L,R=302], fwiw |
| 09:08 | <mathiasbynens> | annevk: what is `ServerName` set to? I guess it’s just `ServerName annevk.nl` — in that case, try `ServerName https://annevk.nl` and restart Apache |
| 09:08 | <annevk> | mathiasbynens: (both also have RewriteEngine on) |
| 09:08 | <annevk> | mathiasbynens: I cannot control Apache |
| 09:08 | <annevk> | (If I could I'd probably not run Apache) |
| 09:09 | <mathiasbynens> | annevk: so no access to mod_rewrite logs either? |
| 09:09 | <annevk> | mathiasbynens: probably do have access to logs |
| 09:11 | <ritsyy> | would this be wrong formatting https://paste.kde.org/prbc0g35f , that was whole in a single line |
| 09:11 | <annevk> | mathiasbynens: actually, so no |
| 09:11 | <mathiasbynens> | annevk: I hope logging is enabled, since you can only enable it from <VirtualHost> which you cannot control |
| 09:11 | <annevk> | mathiasbynens: just normal HTTP logs |
| 09:12 | <annevk> | ritsyy: "Secure Connection Failed" |
| 09:13 | <annevk> | ritsyy: hmm, seems to work in another browser, I guess Nightly is doing some HTTPS experiment |
| 09:13 | <annevk> | ritsyy: IDL should remain on a single line |
| 09:13 | <annevk> | ritsyy: since it's inside <pre> we cannot do wrapping there |
| 09:13 | <ritsyy> | annevk: oh yeah |
| 09:17 | <mathiasbynens> | annevk: not sure how to help, then :( I think it might be the `ServerName` thing. This can be confirmed by placing a test directory at `https://annevk.nl/foo/`, then checking what happens for `curl -I http://annevk.nl/foo` |
| 09:17 | <mathiasbynens> | (that’s `mod_dir`’s `DirectorySlash On` kicking in, which uses the `ServerName` scheme) |
| 09:19 | <annevk> | mathiasbynens: Location: http://annevk.nl/foo/ |
| 09:19 | <mathiasbynens> | annevk: then `ServerName` is just `annevk.nl` or `http://annevk.nl/`, but should be `https://annevk.nl` |
| 09:20 | <annevk> | mathiasbynens: I guess the question is whether there is another workaround apart from just copying the rewriterule from the top-level dir into the annevk.nl dir |
| 09:20 | <mathiasbynens> | annevk: iirc things like mod_dir’s DirectorySlash On and `ErrorHandler`-stuff might take precedence over custom rewrite rules |
| 09:21 | <mathiasbynens> | annevk: if you can’t change the Apache config: not that I know of |
| 09:21 | <annevk> | mathiasbynens: to be clear, if I copy the rewriterule from the top-level dir into the annevk.nl dir it works |
| 09:22 | <mathiasbynens> | annevk: cool, but you’d still have the `Location: http://annevk.nl/foo/` problem I guess |
| 09:22 | <annevk> | mathiasbynens: no |
| 09:22 | <annevk> | mathiasbynens: although it will take two redirects |
| 09:24 | <annevk> | mathiasbynens: the problem seems to be mostly about how rewriterules are combined across directories |
| 09:26 | <mathiasbynens> | annevk: could `RewriteBase` have anything to do with this? are you setting that explicitly for each `.htaccess` file? |
| 09:27 | <annevk> | It sounds like I want http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteoptions Inherit |
| 09:27 | annevk | goes to try that |
| 09:28 | <annevk> | that works |
| 09:28 | <annevk> | great |
| 09:28 | <mathiasbynens> | TIL |
| 09:28 | <mathiasbynens> | hmm, wouldn’t this potentially mess things up? “Rules inherited from the parent scope are applied after rules specified in the child scope.” |
| 09:28 | <annevk> | happy to help :p |
| 09:29 | <annevk> | oh |
| 09:29 | <annevk> | TIL |
| 09:29 | <annevk> | mathiasbynens: I guess I should do InheritDownBefore |
| 09:30 | <annevk> | mathiasbynens: that will cause duplicate redirects but that's fine, since that initial redirect is really only for those not privy to HSTS |
| 09:31 | <mathiasbynens> | 👍🏻 |
| 09:31 | <annevk> | HTTP/1.1 500 Internal Server Error nice |
| 09:33 | <annevk> | Oh great, DreamHost only supports Inherit since it's still stuck on 2.2 |
| 09:35 | <annevk> | So I guess the answer is duplication for each host that wants to use mod_rewrite |
| 09:35 | <annevk> | Okay... |
| 10:08 | <ritsyy> | annevk: https://github.com/whatwg/html/pull/699, thinking where should the attributes be placed then? (supported on documents and elements) |
| 10:09 | <annevk> | ritsyy: and they're not exposed on Window? |
| 10:09 | <ritsyy> | annevk: no |
| 10:10 | <annevk> | I would have assumed browsers to just put them on GlobalEventHandlers |
| 10:11 | <annevk> | hallvors: did you look into this? |
| 10:18 | <hallvors> | annevk: without looking up GlobalEventHandlers those are also available on window, right? per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3888 clipboard ones are on document, elements but not window |
| 10:18 | <ritsyy> | annevk: amm so putting them it in GlobalEventHandlers list (https://html.spec.whatwg.org/multipage/webappapis.html#globaleventhandlers), but it has to be defined in this list right? https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-attributes sorry for the confusion |
| 10:19 | <annevk> | hallvors: yeah, so I guess these are special then |
| 10:19 | <hallvors> | I suppose it wouldn't be a problem adding them to GlobalEventHandlers but it doesn't seem to be what browsers do right now |
| 10:20 | <hallvors> | (and perhaps adding them would conflict with scripts doing function oncopy(){} or var oncopy = ... in global scope..?) |
| 10:20 | <annevk> | ritsyy: I guess what needs to be done is have something called DocumentAndElementEventHandlers that is almost like GlobalEventHandlers but is not implemented by Window |
| 10:20 | <annevk> | hallvors: yeah, let's not even try it, too much compat fallout each time we do something like that |
| 10:20 | <hallvors> | The web platform is full of special sauce :-] |
| 10:22 | <ritsyy> | annevk: okay so i should add by making a different list for it in https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-attributes |
| 10:23 | <annevk> | ritsyy: yeah, I would put a new section before "Event handlers on elements, Document objects, and Window objects" that is almost like it, but doesn't include Window objects |
| 10:23 | <annevk> | ritsyy: and then in the IDL definitions section later on, add a new interface before GlobalEventHandlers |
| 10:24 | <annevk> | ritsyy: and then we need to make sure Document and Element implement that new interface you define, similar to how they implement GlobalEventHandlers today |
| 10:24 | <annevk> | ritsyy: thank you for sorting this out, this is really useful |
| 10:25 | <ritsyy> | annevk: okay the interface be added as DocumentEventHandler? |
| 10:25 | <annevk> | ritsyy: I would say DocumentAndElementEventHandlers since it's also for Elements |
| 10:27 | <ritsyy> | annevk: yes, will complete this change first then this step needs more of understanding for me " Document and Element implement that new interface you define, similar to how they implement GlobalEventHandlers today", how should i do this |
| 10:28 | <ritsyy> | annevk: happy to work on it :) |
| 10:28 | <annevk> | ritsyy: so you'll see that document has "Document implements GlobalEventHandlers;" in its IDL and elements have something similar |
| 10:28 | <annevk> | ritsyy: that is the magic line that makes an interface implement another interface |
| 10:29 | <annevk> | ritsyy: so we want to add a line there for this new interface |
| 10:30 | <ritsyy> | annevk: okay yes now i got that, great |
| 10:30 | <ritsyy> | annevk: will do it now, thanks a lot! |
| 10:44 | <zcorpan> | annevk: /img/daddy probably needs to have the font as a data: URL, since SVG's from 'content' can't reference external resources, right? |
| 10:45 | <annevk> | zcorpan: aah, sounds likely |
| 10:47 | <annevk> | zcorpan: seems like the data URI kitchen doesn't support HTTPS properly, I guess maybe it fails on SNI |
| 10:52 | <zcorpan> | annevk: ok, but you could do a file upload |
| 10:54 | <annevk> | zcorpan: already done and seems to work |
| 10:55 | <zcorpan> | annevk: ah ok. yep works here also |
| 10:57 | <annevk> | thank you for noticing |
| 10:57 | <annevk> | I always thought it looked ugly, but I was assuming it was just a bug |
| 10:57 | <annevk> | (in the browser) |
| 10:58 | <zcorpan> | np. i think the font did work in some browser before. at least sometimes. |
| 11:44 | <nox> | annevk, heycam|away, Ms2ger: https://github.com/heycam/webidl/pull/91 |
| 11:45 | <nox> | 06:49 <annevk> nox: maybe, what do browsers do? <- I'm not sure I understand that question (re ByteString vs DOMString in WebSocket), should there be observable difference about this in UAs? |
| 11:52 | <Ms2ger> | nox, pointer? |
| 11:53 | <nox> | Ms2ger: Pointer? |
| 11:53 | <Ms2ger> | About the WebSocket question |
| 11:54 | <nox> | Ms2ger: http://logs.glob.uno/?c=freenode%23whatwg&s=14+Feb+2016&e=14+Feb+2016&h=protocols#c985140 |
| 11:57 | <Ms2ger> | Ah |
| 12:05 | <annevk> | nox: yeah, ByteString throws for a lot more input iirc |
| 12:05 | <nox> | annevk: Ah? |
| 12:05 | <annevk> | nox: I think it only accepts code points in the 00-FF range |
| 12:07 | <annevk> | nox: nice PR, heycam|away and bz should probably review it |
| 12:07 | <nox> | annevk: Cool. :) |
| 13:31 | <zcorpan> | <meta http-equiv=default-style> is implemented in webkit/blink/gecko. default-style HTTP header only in gecko. :-| |
| 16:14 | <ritsyy> | i am not able to find this section https://html.spec.whatwg.org/multipage/indices.html#all-interfaces :-/ |
| 16:15 | <annevk> | ritsyy: I think that is generated |
| 16:16 | <annevk> | ritsyy: so if you add an interface that will go there automatically |
| 16:17 | <ritsyy> | annevk: yeah i thought that too, but was not sure :) |
| 16:35 | <ritsyy> | build-script is still giving the same errors as "Parsing... |
| 16:35 | <ritsyy> | Parse Error: (117129,9) unexpected body end tag |
| 16:35 | <ritsyy> | " |
| 16:36 | <ritsyy> | i did change the script as annevk suggested that day but everytime different error comes up |
| 16:40 | <annevk> | ritsyy: you shouldn't have to modify the script |
| 16:40 | <annevk> | ritsyy: you might have to update wattsi |
| 16:40 | <annevk> | ritsyy: for both wattsi and html-build you should run "git pull" |
| 16:41 | <annevk> | ritsyy: and build both in the same way you did before |
| 16:41 | <annevk> | I suspect you may not have the latest version |
| 16:41 | <ritsyy> | ritsyy: i did git fetch upstream |
| 16:41 | <annevk> | ok |
| 16:41 | <ritsyy> | then git merge upstream/master |
| 16:42 | <ritsyy> | but it says already up-todate |
| 16:42 | <annevk> | okay |
| 16:43 | <annevk> | did you build wattsi again and make sure PATH points to this new version? |
| 16:44 | <ritsyy> | annevk: amm how to check wattsi's version |
| 16:44 | <annevk> | ritsyy: there isn't a way yet |
| 16:45 | <annevk> | ritsyy: however, when you run build you know where it ends up, so if you point PATH to that and remove other versions you may have, you should be good |
| 16:45 | <ritsyy> | annevk: okay i am doing this |
| 16:47 | <ritsyy> | annevk: this error is their in wattsi https://paste.kde.org/pri9rrymc |
| 16:49 | <annevk> | ritsyy: did you create it with sudo the last time? |
| 16:49 | <annevk> | ritsyy: you may have to empty the bin directory with sudo first |
| 16:49 | <annevk> | ritsyy: and then run the build script without sudo |
| 16:50 | <ritsyy> | annevk: might be, oh okay doing it |
| 17:15 | <nox> | annevk: What's the state of DOMException in the Web? Does only Firefox implement a constructor for these? |
| 17:28 | <annevk> | nox: perhaps, but that should be stable |
| 17:28 | <nox> | annevk: What do you mean? |
| 17:32 | <annevk> | nox: that DOMException as specified is unlikely to change |
| 17:34 | <nox> | So Firefox should drop its constructor? |
| 17:37 | <annevk> | nox: isn't the constructor specified? |
| 17:37 | <nox> | annevk: Where? |
| 17:38 | <annevk> | nox: https://heycam.github.io/webidl/#es-DOMException-constructor-object |
| 17:39 | <nox> | annevk: I can't navigate that spec. -_- |
| 17:39 | <nox> | Never mind me. :) |
| 17:39 | <annevk> | nox: you basically want to always look for what section 4 says about a particular thing |
| 17:39 | <nox> | annevk: Ok. I am taking note of this. |
| 17:40 | <annevk> | nox: at some point Domenic will have time and section 3 will disappear; the distinction between IDL types and ECMAScript types is not super helpful |
| 17:41 | <Domenic> | nox: Chrome implements the constructor now |
| 17:42 | <nox> | Domenic: Oh ok. |
| 18:34 | <nox> | Couldn't DOMException be defined with a proper interface and a new extended attribute [LegacyErrorClass]? |
| 18:37 | <annevk> | nox: I don't think that would buy us much, would just make things more complicated |
| 18:38 | <nox> | annevk: It would eliminate prose and make it clear that it can piggyback IDL's stuff in UAs. |
| 18:38 | <nox> | AFAICT, it has both the usual interface object an interface prototype object that interfaces have, and the codes can just be consts. |
| 18:40 | <annevk> | no it doesn't |
| 18:41 | <annevk> | it inherits from Error |
| 18:43 | <nox> | annevk: Hence LegacyErrorClass, like LegacyArrayClass. |
| 18:45 | <annevk> | I doubt that is going to help much |
| 18:46 | <nox> | annevk: http://heycam.github.io/webidl/#es-DOMException-call I guess that's a special snowflake too? |
| 18:46 | <nox> | annevk: I think I'm at least going to implement LegacyErrorClass in Servo anyway because I think it can help implementation there. I will report back about it then. |
| 18:46 | <annevk> | not sure |
| 18:47 | <caitp> | can you imagine if you could get away with just discarding all of the special snowflakes in the platform? |
| 18:47 | <nox> | caitp: But what would we do then?! |
| 18:47 | <caitp> | go on vacation |
| 18:48 | <nox> | Don't you do that already? |
| 18:48 | <caitp> | sure but getting rid of all the nonsense from the platform would probably be grounds for a good long one |
| 19:24 | <TabAtkins> | Domenic: <https://www.w3.org/2001/tag/doc/promises-guide#example-environment-ready>; uses "in parallel" in exactly the way I keep saying I read it (the following substeps are independent and run parallel with each other), which is *not* the way it's defined (these substeps are a serial algorithm which is run in parallel with the rest of the steps in the outer |
| 19:24 | <TabAtkins> | algorithm), *despite linking to the definition of "in parallel"*. This is why I keep saying that "in parallel" is *not* a good phrase to use for this behavior. |
| 19:25 | <TabAtkins> | It has two natural ways of reading it which are not equivalent, and people will continue to make these kinds of mistakes. :/ |
| 20:10 | <annevk> | TabAtkins: it's an ordered set of steps though... |
| 20:11 | <annevk> | TabAtkins: anyway, you could write a PR against HTML and all the dependencies... |
| 20:11 | <annevk> | TabAtkins: I think everyone else is fine with this term though |
| 20:11 | <annevk> | TabAtkins: that is, I've only seen you make that interpretation |
| 20:14 | <TabAtkins> | annevk: No, in that example the two substeps are *not* ordered. They're two independent conditions that get run in parallel with each other. |
| 20:16 | <annevk> | Oh I see, it shouldn't use numbered steps then |
| 20:16 | <annevk> | One of is always <ul> |
| 20:24 | <TabAtkins> | Yeah, but regardless of the markup, the prose is clearly applying the "in parallel" to those substeps, not to the subalgorithm+outer algorithm |
| 20:24 | <TabAtkins> | (Because there's nothing returned by the previous step, nor is there any following steps in the outer algo.) |
| 20:25 | <annevk> | TabAtkins: it's not multiple substeps though, it's a "pick one of these" which uses <li> for clarity |
| 20:26 | <annevk> | Also, that definition seems wonky, since it'll return a new promise each time |
| 20:27 | <annevk> | I don't really understand how that text can work as-is, best not copy that |
| 20:29 | <TabAtkins> | I'm not copying it, I was looking at it for other reasons. Domenic, ^^ |
| 20:29 | <TabAtkins> | The algo doesn't return anything, so yeah, I also agree the text is wonky and doesnt' wrok well as an example. |
| 21:07 | <Domenic> | annevk: nox: IMO we do need some IDL for defining exception subclasses. A few people have wanted that for media errors with extra properties etc. |
| 21:08 | <Domenic> | TabAtkins: there the work is done by "when/if", not "in parallel" |
| 21:08 | <nox> | Domenic: Could you explain to me how is WebIDL's current DOMException's constructor a special snowflake, compared to an plain old interface constructor? |
| 21:08 | <Domenic> | TabAtkins: as well as "wait for one of the following to become true" |
| 21:08 | <Domenic> | TabAtkins: I can see that the subset formulation is not great; they should probably be bullets |
| 21:09 | <Domenic> | TabAtkins: the only actual thing that happens in parallel is "wait for one of the following to become true" |
| 21:09 | <Domenic> | nox: it is meant to emulate ES Error subclasses |
| 21:10 | <Domenic> | nox: which e.g. can be called, not just constructed |
| 21:10 | <Domenic> | nox: also ideally it defines data properties |
| 21:10 | <nox> | In which UA can it be called? |
| 21:10 | <Domenic> | nox: https://github.com/heycam/webidl/issues/55 |
| 21:12 | <nox> | Domenic: What do you think of [LegacyErrorClass]? |
| 21:12 | <Domenic> | nox: it seems reasonable, see my last comment in that thread. I'd prefer it be spelled [ErrorClass] or s/interface/exception though. |
| 21:13 | <Domenic> | nox: there seem to be a lot of non-legacy use cases for it |
| 21:13 | <nox> | Domenic: Do we want that to be used in specs and whatnot? |
| 21:13 | <nox> | Ok. |
| 21:13 | <Domenic> | It should be used sparingly and rarely |
| 21:13 | <Domenic> | but it's not legacy |
| 21:13 | <nox> | Fair enough. |
| 21:14 | <nox> | Domenic: Should it stay in WebIDL afterwards, or move back to DOM? |
| 21:15 | <nox> | (DOMException that is, not [ErrorClass].) |
| 21:15 | <Domenic> | nox: hmm, I'd still say Web IDL. It's "foundational". |
| 21:15 | <Domenic> | doesn't have much to do with trees of nodes |
| 21:15 | <Domenic> | If we were naming it today I'd say "WebException" (and also fix a lot of other things about it, but sigh) |
| 21:16 | <nox> | Ah ah. |
| 21:16 | <nox> | Domenic: You can disguise and present it as some sort of tradition. |
| 21:16 | <nox> | WebIDL got DOMException, |
| 21:16 | <nox> | DOM got HTMLCollection. |
| 21:18 | <Domenic> | :P |
| 21:26 | <Domenic> | TabAtkins: how do I debug "could not find 'ready' in bibliography data". It doesn't give me a line number that I can see. |
| 21:27 | <Domenic> | TabAtkins: ah it's my use of [[ready]] nevermind |
| 21:27 | <TabAtkins> | Sorry about no line numbers, it's somewhere between "very hard" and "impossible" to fix with lxml. |
| 21:28 | <Domenic> | TabAtkins: could you do the surrounding text node contents? |
| 21:29 | <Domenic> | Just didn't know what to Ctrl+F for |
| 21:36 | <gsnedders> | TabAtkins: why is line numbers hard to fix with lxml? |
| 21:36 | <TabAtkins> | Becasue lxml drops the line numbers on a fucking whim. |
| 21:36 | <gsnedders> | TabAtkins: el.sourceline? |
| 21:36 | <TabAtkins> | Nope, that's null for everything but <html>. |
| 21:36 | <TabAtkins> | Common problem if you look it up. |
| 21:36 | <gsnedders> | oh, with lxml.html? |
| 21:37 | <TabAtkins> | Yeah. |
| 21:39 | gsnedders | wonders if that's an libxml2 or lxml bug |
| 23:00 | <MikeSmith> | TabAtkins: It seems like you may have also run into the the problem that the lxml html5parser ignores the “namespaceHTMLElements=False” option |
| 23:00 | <MikeSmith> | http://stackoverflow.com/questions/32731479/lxml-html5parser-ignores-namespacehtmlelements-false-option |
| 23:01 | <TabAtkins> | I use a custom serializer anyway, so that's unimportant luckily. |
| 23:02 | <MikeSmith> | ah ok |
| 23:06 | <TabAtkins> | (But if I recall correctly, I added that argument originally because it *was* printing namespaces on all the html elements, and adding it made it stop, so apparently it did work in the past, or does work for some printing methods, or something.) |
| 23:11 | <MikeSmith> | interesting |
| 23:11 | <MikeSmith> | I don’t know how else I could call it differently. I was just testing with a simple toString call |
| 23:12 | <MikeSmith> | tostring(h5.parse(stdin, h5.HTMLParser(namespaceHTMLElements=False))) |
| 23:12 | <MikeSmith> | where h5 is html5parser |
| 23:24 | <TabAtkins> | Actually, I still use html.tostring(0 |
| 23:24 | <TabAtkins> | I only use my custom serializer for outputting the final document. |
| 23:30 | <TabAtkins> | MikeSmith: Yeah, namespaceHTMLElements definitely makes a difference for me. |
| 23:31 | <TabAtkins> | https://www.irccloud.com/pastebin/SeFw0lLC/ |
| 23:34 | <TabAtkins> | I'm calling html5lib directly, tho, not relying on anything built into lxml. |
| 23:34 | MikeSmith | looks |
| 23:34 | <MikeSmith> | ah yeah |