| 03:21 | <MikeSmith> | tripu: all *.w3.org domains seem to be unreachable right now |
| 03:23 | <MikeSmith> | tripu: including mail services, so it's not possible even to send mail to sysreq to alert anybody |
| 03:25 | <MikeSmith> | tripu: ...and now it seems to be back |
| 04:05 | <sicking> | v |
| 05:35 | <cs0sf_> | good documentation , is there html book version also available? |
| 08:28 | <blue-grapes> | Hello guys, anybody here? |
| 08:30 | <Ms2ger> | Nope |
| 08:34 | <blue-grapes> | Anybody has idea on how to code in tables through this layout? http://postimg.org/image/nireggyvh/ |
| 10:26 | <JakeA> | annevk: am in the office for once, if there's anything I should be looking at (going to go through inbox & github otherwise) |
| 10:30 | <annevk> | JakeA: the client/context bug; the 304 handling bug |
| 10:31 | <JakeA> | annevk: just replied to the former, will look at the latter now |
| 11:17 | <annevk> | JakeA: I'm looking into adding a fromCache member to responses |
| 11:17 | <annevk> | JakeA: perhaps call it "cache state" |
| 11:18 | <annevk> | JakeA: none / local / validated / partial |
| 11:18 | <annevk> | JakeA: not sure if we need something for synthetic responses |
| 11:25 | <annevk> | Anyone here with recent knowledge on WebVTT? I'm asked to ignore certain lines in the header of files, but it seems sort of weird to me: https://github.com/annevk/webvtt/pull/6 |
| 11:42 | <jgraham> | Wow I missed the whole W3C Dev Campus thing |
| 11:43 | <jgraham> | It offers to "get rid of your web deficiencies" |
| 11:44 | <jgraham> | Sorry s/web/Web/ |
| 11:45 | <hallvors> | Spec interpretation question coming up - bear with me .. |
| 11:45 | <annevk> | Learning fast jgraham! |
| 11:45 | <hallvors> | https://html.spec.whatwg.org/multipage/browsers.html#javascript-protocol says: |
| 11:45 | <hallvors> | 10. Let address be the address of the active document of the browsing context being navigated. |
| 11:45 | <hallvors> | If you're inserting <IFRAME src="javascript:..."> into a document, what is "the active document of the browsing context being navigated"? |
| 11:46 | <annevk> | hallvors: <iframe> is initially about:blank; so the document generated by that |
| 11:46 | <annevk> | jgraham: although I would spell it with a small w |
| 11:46 | <hallvors> | OK - that's what I think Chrome does |
| 11:46 | <hallvors> | but it's not clear to me from https://html.spec.whatwg.org/multipage/embedded-content.html#process-the-iframe-attributes |
| 11:46 | <annevk> | jgraham: the whole, there's only one of them so we need to use uppercase is a weird rule |
| 11:47 | <annevk> | hallvors: I think that's because that's not where it starts |
| 11:47 | <annevk> | hallvors: first the <iframe> is created |
| 11:47 | <hallvors> | is the "resolve" part not successful for javascript: ? |
| 11:47 | <hallvors> | hm.. |
| 11:47 | <annevk> | hallvors: 'When an iframe element is inserted into a document that has a browsing context, the user agent must create a nested browsing context, and then process the iframe attributes for the "first time".' |
| 11:47 | <annevk> | hallvors: create a nested browsing context is key here |
| 11:48 | <hallvors> | OK - thanks, I'll go back and look :) |
| 11:48 | <annevk> | hallvors: you could file a bug on Hixie not linking "create" |
| 11:48 | <jgraham> | annevk: The Guardian style guide has a small "w". I don't think there's a special rule about singletons |
| 11:48 | <annevk> | jgraham: hsivonen told me that when I spelled internet lowercase |
| 11:48 | <annevk> | jgraham: or maybe it was Hixie |
| 11:48 | <jgraham> | annevk: The Guardian disagrees with him on that too |
| 11:49 | <jgraham> | All these rules are basically made up |
| 11:49 | <annevk> | jgraham: good, I agree with The Guardian then :p |
| 11:49 | <annevk> | hallvors: I'll file a bug on linking create |
| 11:49 | <hallvors> | thx |
| 11:50 | <jgraham> | (fwiw Chicago manual of style has web and Internet |
| 11:50 | <annevk> | hallvors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27029 |
| 11:51 | <annevk> | jgraham: we better set up howdoyouspellwebandinternet.com |
| 11:52 | <hallvors> | so, naturally there is a follow-up question: in "process the IFRAME attributes" prose, there's this: |
| 11:52 | <hallvors> | "If there exists an ancestor browsing context whose active document's address, ignoring fragment identifiers, is equal to url, then abort these steps." |
| 11:53 | <hallvors> | embedding a src=javascript: IFRAME inside a src=javascript: IFRAME will now fail |
| 11:53 | <hallvors> | because presumably this step will prevent embedding about:blank inside about:blank ? |
| 11:54 | <annevk> | hallvors: I think it prevents nesting e.g. http://example/test into http://example/test, no? |
| 11:54 | <hallvors> | yes, that's the intention |
| 11:55 | <hallvors> | but given that the "address" of javascript:'string of html' documents is now about:blank - we'll end up here, right? |
| 11:55 | <hallvors> | (context - FYI - is me trying to figure out if aligning with HTML5 would fix Gecko bug 836567) |
| 11:56 | <hallvors> | Chrome does set URL to about:blank, but does not prevent nesting. But I think if it was implementing this algorithm to the t, it would |
| 11:57 | <hallvors> | (So I think this step perhaps needs an exception for about:blank or something) |
| 11:57 | <hallvors> | (and perhaps add a general "don't nest browsing contexts deeper than you'd like to" step instead) |
| 11:57 | <annevk> | hallvors: no, about:blank is the <iframe>'s document, not its ancestor |
| 11:58 | <hallvors> | annevk: I'm looking at an IFRAME nested *inside* an IFRAME |
| 11:58 | <hallvors> | so there certainly is an ancestor with the address about:blank |
| 11:58 | <hallvors> | (see TC in bugzilla) |
| 12:01 | <annevk> | Okay, I see what you're saying |
| 12:02 | <annevk> | hallvors: did you point to the bug already? |
| 12:02 | <hallvors> | 836567 |
| 12:02 | <hallvors> | https://bugzilla.mozilla.org/show_bug.cgi?id=836567 |
| 12:04 | <annevk> | hallvors: "If there exists an ancestor browsing context whose active document's address, ignoring fragment identifiers, is equal to url, then abort these steps." at this point /url/ is the javascript URL, no? |
| 12:05 | <annevk> | hallvors: how could that be equal to an ancestor that has about:blank as URL? |
| 12:05 | <hallvors> | no, per what you just said above URL is about:blank - because that's the "address of the active document of the browsing context being navigated" which we're supposed to use as the "override URL" of the document |
| 12:06 | <hallvors> | hm.. |
| 12:06 | <hallvors> | no, you may be right |
| 12:09 | <hallvors> | that's what I was missing ;). |
| 12:09 | <hallvors> | Now, what happens (or not) if you load about:blank URLs inside src:javascript: IFRAMEs? It just "falls back" to the document the browsing context was created with - right? |
| 12:12 | <annevk> | hallvors: what do you mean by load? |
| 12:13 | <hallvors> | s/load/embed an IFRAME loading |
| 12:14 | <annevk> | that new <iframe> will get its own document, yes |
| 12:27 | <hallvors> | now, if we hit "If there exists an ancestor browsing context whose active document's address, ignoring fragment identifiers, is equal to url, then abort these steps" and this algorithm is aborted - does HTML5 still require firing a load event for that IFRAME? |
| 12:28 | <hallvors> | yes - happens further down "When a Document in an iframe is marked as completely loaded, the user agent must run the iframe load event steps in parallel." |
| 12:28 | <hallvors> | it's amusing that Chrome supports giving about:blank a query string, so I can nest lots of about:blank IFRAMEs :) |
| 12:29 | <hallvors> | but only in Chrome - in other browsers that's a load failure.. |
| 12:33 | <annevk> | per the URL spec that ought to work |
| 12:33 | <annevk> | well, Fetch spec, sorry |
| 12:33 | <annevk> | see https://fetch.spec.whatwg.org/#basic-fetch (it does not check for query being null) |
| 12:45 | <JakeA> | annevk: of the cacheMode stuff, what dictates if I get a 304 back or not? |
| 12:46 | <annevk> | JakeA: the mode? |
| 12:47 | <JakeA> | annevk: I'm reading https://github.com/slightlyoff/ServiceWorker/issues/412#issuecomment-58646963 and it's unclear which result in me getting back the 304. It says some explicitly don't, but not sure about the others |
| 12:48 | <annevk> | JakeA: they would |
| 12:48 | <JakeA> | annevk: I mean, is the only way for me to get a 304 response is to set if- headers myself? |
| 12:49 | <annevk> | JakeA: that depends on the server |
| 12:49 | <JakeA> | annevk: If I don't set If- headers manually, what are the conditions for getting a 304 response object back as a result of calling fetch(url)? |
| 12:50 | <annevk> | JakeA: I'm not sure what you mean, surely that depends on the server |
| 12:51 | <JakeA> | annevk: At the moment, with XHR, I can only get access to a 304 response if I set "If-" headers myself. Otherwise it returns the cached entry. Has this changed? |
| 12:52 | <annevk> | JakeA: not if cache mode is default |
| 12:53 | <JakeA> | annevk: ok, so assuming I'm *not* setting "If-" headers myself, and the server returns a 304, what are the conditions for me getting that 304 response in script? |
| 12:54 | <annevk> | JakeA: mode needs to be bypass or reload |
| 12:54 | <annevk> | JakeA: or force cache I suppose, though that'd be a bit weird |
| 13:07 | <JakeA> | annevk: What happens to my "If-" headers if I set the mode to be "revalidate"? |
| 13:07 | <annevk> | JakeA: I'm not sure |
| 13:08 | <annevk> | JakeA: should ask mayhemer I guess |
| 13:08 | <annevk> | JakeA: will you? |
| 13:08 | <JakeA> | annevk: My gut says that mode gets set to "bypass" |
| 13:08 | <JakeA> | yeah, will ask |
| 13:08 | <annevk> | not opposed, but he didn't seem to like that behavior |
| 13:09 | <JakeA> | hm, but we're already doing that for "default" |
| 13:09 | <annevk> | yes |
| 13:09 | <annevk> | this cache stuff is hard, and we haven't even dug down into everything |
| 13:10 | <annevk> | gave up on figuring out how to deal with partial content |
| 13:11 | <JakeA> | annevk: yeah, I've been wondering what to do if you get a fetch event with a range, and you respond with something from the cache |
| 13:19 | <annevk> | JakeA: if reply with a 200 and the full resource it's okay |
| 13:19 | <annevk> | you* |
| 13:19 | <annevk> | JakeA: seems like you need to reply with a 206 and a range from the cache otherwise |
| 13:19 | <annevk> | JakeA: not sure if the cache supports slicing? |
| 13:23 | <JakeA> | annevk: nope. But as you say, a 200 response would do the right thing. |
| 13:27 | <annevk> | JakeA: still seems like something we should support down the road |
| 13:27 | <JakeA> | annevk: oh agreed |
| 14:29 | <MikeSmith> | hsivonen: validator.nu and html5.validator.nu still 502 |
| 14:30 | <MikeSmith> | hsivonen: hoping it's not something I broke somehow (but don't know how it could be if you've not redeployed recently) |
| 14:33 | <zcorpan> | annevk: is halting on error in a url something that anyone has asked for? |
| 14:34 | <annevk> | zcorpan: some people did, not sure how strong the request was though |
| 14:34 | <annevk> | zcorpan: feel free to argue against it, haven't really made up my mind |
| 14:36 | <zcorpan> | annevk: are the requests public? |
| 14:36 | <annevk> | zcorpan: might be in some old thread somewhere |
| 16:06 | <jgraham> | erlehmann: Is that the kind of "broke" where they are suddenly without a "browsers" table in their db, or the kind of "broke" where the page formatting looks wrong for that one load |
| 16:06 | <jgraham> | ? |
| 16:07 | <jgraham> | (I don't really think it's a security issue either way since it would still be a site-controlled value) |
| 16:09 | <erlehmann> | jgraham it is the kind of broke where there is an SQL injection possible if you know how the table is named |
| 16:09 | <erlehmann> | i think xss is not an issue |
| 16:10 | <erlehmann> | jgraham enough stats package do not seem to sanitize the UA string that I would consider it dangerous to let arbitrary js set it to a value. |
| 16:10 | <jgraham> | From the point of view of the site, the js is supposed to be more trusted than the user, who can already set the value |
| 16:11 | <jgraham> | Well I guess Cross-Origin requests are a bit different |
| 17:18 | <annevk> | Hixie: if "environment settings object" has a 1:1 with its global object, why are they distinct? |
| 17:19 | <Hixie> | they are distinct because we need something to hook all the configuration of an environment in. That there are parts of it that have a 1:1 mapping seems irrelevant. |
| 17:19 | <Hixie> | i mean, why do we have a Location object? it has a 1:1 mapping with a Window object |
| 17:20 | <Hixie> | why do we have both a parsed URL and a serialised URL? they have a 1:1 mapping too |
| 17:26 | <annevk> | Not sure about that last one, but fair enough I guess... |
| 17:27 | <annevk> | Hixie: would it work if I just renamed "client" to "environment" and made its value an environment settings object? |
| 17:29 | <annevk> | Hixie: ok if I file a bug asking for a slightly more explicit description of the members? E.g. whether https://html.spec.whatwg.org/multipage/webappapis.html#responsible-document is null in a worker environment? |
| 17:29 | <annevk> | Hixie: that is, type descriptions for the members of an environment settings object would be nice, probably mostly whether they can be null |
| 17:31 | <annevk> | Hmm, an intent to implement on blink with a TR/ URL |
| 17:31 | <annevk> | blink-dev* |
| 17:31 | <Domenic> | yeah, saw that... |
| 17:32 | <annevk> | Domenic: writing a Twitter bit is pretty easy btw |
| 17:32 | <annevk> | Twitter bot |
| 17:33 | <annevk> | Although keeping it alive is not... |
| 17:33 | <Domenic> | annevk: it needs to actively be scanning for people tweeting /TR/ URLs though |
| 17:33 | <Domenic> | annevk: that said I probably could use one for streams |
| 17:34 | <Domenic> | Also I just ordered a bunch of WHATWG logo stickers so if anyone sees me in person ask and they're yours |
| 17:34 | <annevk> | I once created https://twitter.com/w3cdrm but that didn't really follow the tweets of everyone |
| 17:34 | <Domenic> | haha |
| 17:35 | <annevk> | But if they have an API for getting everyone's tweets it should be relatively straightforward |
| 17:35 | <Domenic> | yeah should be a fun side project |
| 17:35 | <annevk> | Through https://script.google.com/ you can do it in JavaScript and no need to host anything yourself |
| 17:36 | <annevk> | Domenic: I tried sharing the code with you |
| 17:36 | <annevk> | Domenic: should be easy enough to adjust |
| 17:48 | <Hixie> | annevk: you can even leave it named client, :-) |
| 17:48 | <Hixie> | annevk: the responsible document is not null in workers |
| 17:51 | <annevk> | Hixie: oh, even for shared workers? |
| 18:09 | <Hixie> | annevk: yeah. i think it might never be used though. |
| 18:10 | <annevk> | Might be nice if we could recast any use in workers in terms of the settings object instead |
| 18:11 | <Hixie> | doesn't HTML already do that? |
| 18:18 | <JonathanNeal> | does anyone remember the recommended way to use blockquote? I remember there being a html5 doctor article about it, but then i remember a discussion that argued it should be used another way. |
| 18:19 | <JonathanNeal> | This was an older discussion, but I remember something about using <footer> or something. |
| 18:25 | <annevk> | Hixie: I'll study it, thanks for the help thus far |
| 18:26 | <boogyman> | JonathanNeal: <blockquote><some block level element>…</element></blockquote> |
| 19:39 | <say2joe> | JonathanNeal: you may be thinking about using footer in terms of the cite attribute … http://www.w3.org/TR/html5/grouping-content.html#the-blockquote-element |
| 19:54 | <Hixie> | JonathanNeal: <blockquote></blockquote><p><cite></cite><p> or some such |
| 19:54 | <Hixie> | JonathanNeal: depending on what you want exactly |
| 20:12 | <JonathanNeal> | Thanks, Hixie. |