| 01:32 | <annevk> | So that is weird... For @WHATWG to stop and html5.org to continue... |
| 01:44 | <annevk> | So it seems a Python module has disappeared |
| 01:47 | <GPHemsley> | Hixie: How quickly did DreamHost say they were going to upgrade? |
| 02:02 | <annevk> | It seems "{'errors': [{'message': 'The Twitter REST API v1 will soon stop functioning. Please migrate to API v1.1. https://dev.twitter.com/docs/api/1.1/overview.';, 'code': 68}]}" might be the problem :/ |
| 02:02 | <zewt> | nothing encourages using apis like forcing everyone to rewrite things |
| 02:08 | <annevk> | Yeah, not really sure what the right approach is here. |
| 02:10 | <Hixie> | is there a python twitter module we can rely on? |
| 02:10 | <Hixie> | also, woot, an anne online! |
| 02:10 | <Hixie> | there was some bug i was supposed to ask you about |
| 02:11 | <annevk> | Hixie: the GBK thing is not completely sorted out, basically |
| 02:11 | <Hixie> | ah yeah, that's the one |
| 02:11 | <Hixie> | ok |
| 02:11 | <annevk> | Hixie: there's some outstanding questions as to whether we can merge it into gb18030 or not |
| 02:11 | <Hixie> | is there some bug i can follow on that? |
| 02:13 | <annevk> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16862 |
| 02:14 | <Hixie> | awesome |
| 02:14 | <annevk> | Hixie: there's a Python module which we're using. However, I'm having a hard time understanding how Python module updates work, especially across Python versions, etc. |
| 02:15 | <annevk> | Hixie: versioned software development is not something I'm very capable at. And understanding which Python version executes and which modules it'll pick up... I don't even... |
| 02:15 | annevk | prefers browsers |
| 02:15 | <Hixie> | yeah i dunno how it works for python |
| 02:16 | <Hixie> | ok. based on that bug i'm guessing that GB18030 is fine as a default encoding. |
| 02:16 | <Hixie> | gonna call it for now until i get a specific compat complaint. |
| 02:28 | <annevk> | Twitter account will remain broken for a bit until I find someone that can fix the Python setup. Not really interested in going through that while sleep deprived. |
| 02:28 | <annevk> | Twitter account will remain broken for a bit until I find someone that can fix the Python setup. Not really interested in going through that while sleep deprived. |
| 06:38 | <matjas> | Twitter — breaking the web one API endpoint at a time |
| 08:09 | <jgraham> | (In principle I can probably help fix the Twitter thing. Or at least I generally understand how Python works) |
| 11:01 | <Ms2ger> | reyre, [SetterThrows] is Gecko-only, it isn't supposed to end up in specs |
| 11:14 | <mitsuhiko> | hey everybody |
| 11:14 | <mitsuhiko> | does anyone have some authoritive answer in regards to http headers and rfc5987? |
| 11:15 | <mitsuhiko> | it looks like browsers are currently handling this encoding for their internal usage, but xmlhttprequest returns the raw string? |
| 11:16 | <mitsuhiko> | does that mean users of the XMLHttpRequest object are supposed to do that on their own? |
| 13:08 | <SimonSapin> | hsivonen: Do you know about this? (See mitsuhiko’s question above.) |
| 13:30 | <zewt> | did something happen to the styling of the webvtt spec, heh |
| 13:30 | <zewt> | seems hard to read now (but I'm not sure why), and I don't remember getting that impression the last time I opened it |
| 13:32 | <zewt> | oh, it's because the underlined text is black, instead of blue (thanks @ web.archive.org) |
| 13:32 | <zewt> | or maybe because the spacing changed |
| 13:37 | <annevk> | jgraham: still interested? |
| 13:38 | <jgraham> | annevk: In? |
| 13:38 | <jgraham> | The twitter thing? |
| 13:39 | <jgraham> | Sure |
| 13:39 | <jgraham> | Also, probably for most other things that I previously expressed interest in |
| 13:39 | <SimonSapin> | annevk: Do you know about this? http://krijnhoetmer.nl/irc-logs/whatwg/20130613#l-308 |
| 13:39 | <MikeSmith> | annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20130613#l-308 |
| 13:40 | <MikeSmith> | SimonSapin: jinx |
| 13:41 | <annevk> | SimonSapin: the specification doesn't care |
| 13:42 | <annevk> | SimonSapin: well, it treats values as byte sequences, not strings |
| 13:42 | <annevk> | (although it somewhat confusingly exposes them as strings...) |
| 13:42 | <SimonSapin> | mitsuhiko: ^ |
| 13:43 | <mitsuhiko> | annevk: eg: client libraries have to decode the headers by hand? |
| 13:44 | <mitsuhiko> | does that also apply to outgoing headers? |
| 13:44 | <annevk> | mitsuhiko: yeah |
| 13:44 | <annevk> | yeah |
| 13:45 | <annevk> | basically the core HTTP header value type is byte sequences on top of which they created a number more specific value types |
| 13:45 | <annevk> | however, the API only knows about the core HTTP header value type |
| 13:46 | <mitsuhiko> | it's a bit of an unfortunate situation because from what i can see, no javascript high level library actually implements proper header parsing/emitting wrt to unicode |
| 13:49 | <annevk> | it'd be quite complicated to do so even |
| 13:50 | <annevk> | mitsuhiko: you might want to file a bug on http://xhr.spec.whatwg.org/ with the use case for outgoing and incoming headers you have in mind |
| 13:50 | <annevk> | mitsuhiko: it might be worth considering for an upgrade or new API |
| 13:51 | <mitsuhiko> | annevk: i will have to think about this first before i propose anything. I am just going through various unicode related issues for a server side http library right now and wanted to compare with browsers. |
| 13:51 | <annevk> | fair enough |
| 13:52 | <annevk> | in general I think they haven't really designed HTTP headers particularly well |
| 13:53 | <mitsuhiko> | it definitely got worse over time. by now 5 rfcs are involved in encoding and headers: http://greenbytes.de/tech/tc2231/ (not counting the cookie headers) |
| 13:53 | <SimonSapin> | there might have been more evolution than design involved… |
| 13:53 | <mitsuhiko> | SimonSapin: i'm not complaining :) |
| 13:53 | <SimonSapin> | I am :) |
| 14:12 | <GPHemsley> | mitsuhiko: Hey, that's a useful link. Thanks for that! |
| 14:14 | <GPHemsley> | annevk: I'm not too familiar with CSP; I think I got the directive wrong for the regular browsing context |
| 14:14 | <GPHemsley> | annevk: (I used 'connect-src') |
| 14:14 | <GPHemsley> | annevk: Which makes me wonder if there even is a directive for the regular browsing context (maybe 'default-src'?) |
| 14:15 | <GPHemsley> | annevk: Also, it makes me wonder if we need another context for 'connect-src' |
| 14:15 | <GPHemsley> | annevk: Also, it makes me wonder if we need another context for 'connect-src' |
| 14:15 | <annevk> | GPHemsley: I don't think CSP blocks following links |
| 14:16 | <GPHemsley> | perhaps not |
| 14:52 | <GPHemsley> | hmm... |
| 14:53 | <GPHemsley> | parse natural DNA into natural pre-RNA; remove introns from natural pre-RNA to make natural mRNA; serialize natural mRNA into synthetic cDNA; patent synthetic cDNA |
| 14:55 | <GPHemsley> | (that's like saying a potentially-malformed format from the wild is natural and unpatentable, but serializing it into a format that follows the ABNF results in a patentable form) |
| 14:55 | GPHemsley | throws his hands up |
| 16:03 | <zewt> | today's insanity: in mobile safari, body { 50%; } works, but html body { 50%; } gives 25% |
| 16:04 | <Ms2ger> | html, body? |
| 16:05 | <zewt> | no, the real rule is html[something] body |
| 16:05 | <zewt> | oh i see what's happening |
| 16:05 | <zewt> | oh i see what's happening |
| 16:05 | <zewt> | body { zoom: 50%; } body { body: 50%; } becomes 25%, instead of just overriding the rule |
| 16:05 | <zewt> | that's ... batshit insane |
| 16:05 | <zewt> | er, zoom: |
| 16:08 | <SimonSapin> | zewt: is zoom supposed to be the same as scale() in a transform? |
| 16:08 | <zewt> | i'm not sure of the particulars |
| 16:11 | GPHemsley | recalls 'zoom' not being an interoperable property |
| 16:11 | <zewt> | i don't think so: a transform lays the contents out the same way, then scales the result; zoom changes the size of the contents, so it affects the actual flow |
| 16:11 | <Ms2ger> | I thought it was something you used to... Force hasLayout in IE? |
| 16:15 | <GPHemsley> | annevk: I wonder if the 'sandbox' directive might be more appropriate? |
| 16:17 | <GPHemsley> | Hixie: Does HTML treat XHR/WebSocket/EventSource requests as different from <script> requests? |
| 16:43 | GPHemsley | wonders why CSP uses 400 instead of 403 |
| 17:11 | <GPHemsley> | hmm... an XHR/WebSocket/EventSource request is sort of a hybrid between a script context and a (nested) browsing context... |
| 17:12 | <GPHemsley> | leaning more towards the latter |
| 17:44 | <smaug____> | slightlyoff: ping |
| 17:44 | <smaug____> | since annevk isn't here |
| 17:46 | <smaug____> | do you recall why http://dom.spec.whatwg.org/#promises-model requires then-property to be callabke. |
| 17:47 | <smaug____> | it would be simpler to just throw and catch and call reject in case then wasn't callable |
| 17:51 | <slightlyoff> | We're going to go for ghetto branding, not what's there now, methinks |
| 17:52 | Ms2ger | wonders why we're even implementing it now if we're going to have to rewrite everything anyway |
| 17:56 | <smaug____> | Ms2ger: yeah |
| 18:51 | <Hixie> | GPHemsley: yes, but maybe not in the way you care about? not sure what you're asking |
| 18:51 | <Hixie> | hm, floats are hard to use right. |
| 18:51 | <Hixie> | i want something that floats to the right of my paragraph, but comes after the paragraph in the dom |
| 18:51 | <Hixie> | not sure that's even possible |
| 18:52 | <Ms2ger> | Float your paragraph left? |
| 18:52 | <Hixie> | the paragraph is part of a long document |
| 18:52 | <Hixie> | the paragraph is part of a long document |
| 18:53 | <Hixie> | think <p> vs <p class=note> in the spec |
| 18:53 | <Hixie> | i want the .note to float to the right of the p |
| 18:53 | <Ms2ger> | !p + p.note {}? |
| 18:53 | <Hixie> | that doesn't work if i don't know their relative sizes ahead of time |
| 18:53 | <Ms2ger> | Or do you want something that works practically rather than theoretically? |
| 18:53 | <Hixie> | practically, yes |
| 18:54 | <Ms2ger> | No idea, then |
| 18:54 | <Hixie> | (also, really, we're going with the "!" thing? ugh) |
| 18:54 | <Hixie> | (:matches is such a better solution.) |
| 18:55 | <Ms2ger> | I dunno |
| 18:55 | <Ms2ger> | It's not like anybody is implementing |
| 18:58 | <GPHemsley> | what's 1? |
| 18:58 | <GPHemsley> | err, ! |
| 18:58 | <GPHemsley> | what's !? |
| 18:58 | <GPHemsley> | what's !? |
| 19:01 | <Ms2ger> | If you have !a + b { color: green }, the a is green |
| 19:03 | <jgraham> | Hasn't Hixie been promoting :matches since like 2000? |
| 19:03 | <Hixie> | yeah |
| 19:03 | <Hixie> | but i'm not active in the wg |
| 19:03 | <Hixie> | so... :-) |
| 19:04 | <jgraham> | Well yeah, but it's like "<Hixie> We should solve it using :matches" is a permanent feature of the web |
| 21:10 | <GPHemsley> | IDK, ! makes sense to me, now that I remember what it means. |
| 21:10 | <GPHemsley> | since it patterns with !important |
| 21:13 | <GPHemsley> | plus, you'd have to explain to me how :matches would work |
| 21:40 | <Hixie> | GPHemsley: with !, how do you pick an element that has either a <p> next sibling, a <div> next sibling, or an <ol> next sibling? |
| 21:41 | <GPHemsley> | isn't there any() for that? |
| 21:41 | <Hixie> | any is a variant of matches |
| 21:41 | <GPHemsley> | !* :any(p, div, ol) |
| 21:42 | <GPHemsley> | or something |
| 21:42 | <Hixie> | an even better example would be, how do you match an element that has both an <ul> following subling, and an <ol> following sibling |
| 21:42 | <GPHemsley> | when would that happen? |
| 21:42 | <GPHemsley> | or you mean generically |
| 21:42 | <GPHemsley> | not immediately |
| 21:42 | <GPHemsley> | himm |
| 21:42 | <GPHemsley> | -i |
| 21:42 | <Hixie> | you could do it as a pair, as in: !* ~ ul ~ ol, !* ~ ol ~ ul |
| 21:42 | <Hixie> | but that quickly gets out of hand |
| 21:43 | <GPHemsley> | !* ul/ol |
| 21:43 | <Hixie> | with :matches it's just :matches(# ~ ol):matches(# ~ ul) |
| 21:43 | GPHemsley | needs to brush up on his selectors |
| 21:43 | <Hixie> | what's "/"? |
| 21:43 | <Hixie> | what's "/"? |
| 21:43 | <GPHemsley> | dunno |
| 21:43 | <GPHemsley> | dunno |
| 21:43 | <GPHemsley> | just made it up |
| 21:43 | <Hixie> | hah |
| 21:43 | <Hixie> | k |
| 21:43 | <Hixie> | i guess that's fair |
| 21:43 | <Hixie> | i'm making up :matches :-D |
| 21:43 | <GPHemsley> | :) |
| 21:44 | <Hixie> | anyway :matches() is just a pseudo that matches if its selector matches the node in question, with "#" being a placeholder in the argument for "the current element being checked" |
| 21:47 | <GPHemsley> | does :nth-match() help here? |
| 21:47 | <GPHemsley> | (the spec is kinda sparse on examples) |
| 21:47 | <GPHemsley> | (the spec is kinda sparse on examples) |
| 21:48 | <GPHemsley> | oh, it's E! not !E |
| 21:50 | <GPHemsley> | *! ( (~ ul) && (~ ol) ) |
| 21:51 | <GPHemsley> | oh, apparently the spec is not consistent on the placement of the ! |
| 21:56 | <GPHemsley> | oh, apparently :matches() is already in the spec, too |
| 21:56 | <GPHemsley> | but it only takes two arguments? |
| 21:56 | <GPHemsley> | I'm not clear on the syntax here |
| 21:57 | <GPHemsley> | *|*:matches(:hover, :focus) |
| 21:57 | <GPHemsley> | !*:matches(~ ul, ~ol) would probably be the right thing, then |
| 21:57 | <GPHemsley> | ~ ol |
| 21:57 | <GPHemsley> | (are the spaces signficant?) |
| 21:58 | <GPHemsley> | +i |
| 21:58 | <GPHemsley> | (are the spaces signficant?) |
| 21:58 | <GPHemsley> | +i |
| 21:58 | <GPHemsley> | oh, hmm |
| 21:58 | <GPHemsley> | namespaces are confusing |
| 22:06 | <Hixie> | i don't think the :matches() in the spec supports the "#" part i suggested |
| 22:17 | <GPHemsley> | nope |
| 22:17 | <GPHemsley> | but I'm not sure that it needs to |