| 08:13 | <annevk> | zcorpan: technically https://github.com/whatwg/html/pull/2449 was not editorial, existing text would result in a compile error I think |
| 08:17 | <annevk> | I do like your use of the Unicode arrow, I should try to find it next time I have something like this |
| 09:03 | <felixjet> | can someone give me a hand? |
| 09:03 | <felixjet> | the validator is trolling me |
| 09:03 | <felixjet> | Error: Element pre not allowed as child of element figure in this context. |
| 09:04 | <felixjet> | Contexts in which element pre may be used: --> Where flow content is expected. |
| 09:04 | <felixjet> | right. so i can only use <pre> where flow content is expected |
| 09:04 | <felixjet> | Content model for element figure: --> Flow content optionally including a figcaption child element. |
| 09:04 | <felixjet> | so..... wt* |
| 09:04 | <felixjet> | figure accepts flow content |
| 09:04 | <felixjet> | and <pre> must be used where flow content is expected |
| 09:04 | <felixjet> | whats going wrong here? |
| 09:10 | <annevk> | felixjet: I'd file a bug |
| 09:10 | <felixjet> | so i have nothing wrong here? |
| 09:10 | <felixjet> | in case it matters |
| 09:10 | <felixjet> | my structure is: |
| 09:11 | <felixjet> | <figure><div></div><figcaption></figcaption><pre></pre></figure> |
| 09:11 | <felixjet> | maybe i can't use div AND pre? |
| 09:11 | <felixjet> | but the spec doesn't say anything about how many flow content elements are valid |
| 09:11 | <MikeSmith> | the spec says that’s not valid |
| 09:11 | <MikeSmith> | https://html.spec.whatwg.org/multipage/semantics.html#the-figure-element |
| 09:12 | <MikeSmith> | Content model: |
| 09:12 | <MikeSmith> | Either: One figcaption element followed by flow content. |
| 09:12 | <MikeSmith> | Or: Flow content followed by one figcaption element. |
| 09:12 | <MikeSmith> | Or: Flow content. |
| 09:12 | <felixjet> | it just say: |
| 09:12 | <felixjet> | Content model: -> Either: One figcaption element followed by flow content. |
| 09:12 | <MikeSmith> | which spec? |
| 09:12 | <felixjet> | whatwg |
| 09:12 | <felixjet> | i just copied what you just said |
| 09:12 | <felixjet> | so <div></div><pre></pre> is not "flow content" ? |
| 09:13 | <MikeSmith> | <div></div><figcaption></figcaption><pre></pre> is not One figcaption element followed by flow content |
| 09:13 | <felixjet> | why the order does matter? |
| 09:13 | <MikeSmith> | that is flow content followed by figcaption followed by flow content |
| 09:13 | <felixjet> | what if figcaption is in the middle? |
| 09:13 | <MikeSmith> | yeah, that |
| 09:13 | <felixjet> | i mean, why thats now allowed? |
| 09:13 | <felixjet> | not* |
| 09:14 | <MikeSmith> | because that is what the spec requires |
| 09:14 | <felixjet> | but maybe is spec'ed like that because none was thinking about using multiple flow content inside figure |
| 09:14 | <felixjet> | but there shouldn't be any limitation to do so |
| 09:14 | <felixjet> | technically |
| 09:14 | <felixjet> | i'm wrong? |
| 09:15 | <MikeSmith> | it was specified that way intentionally, it is not an oversight |
| 09:15 | <MikeSmith> | the intent is just that the figcaption must be either the first child of the figure or the last child |
| 09:16 | <felixjet> | i was using the div to create a title, the figcaption to describe the figure, and <pre> is the figure itself |
| 09:16 | <felixjet> | but <figcaption><div><pre> is allowed? |
| 09:16 | <MikeSmith> | yup |
| 09:16 | <felixjet> | so... why in me middle is forbidden? |
| 09:16 | <felixjet> | in the* |
| 09:16 | <felixjet> | theres a real reason? |
| 09:16 | <MikeSmith> | because as I said, the intent is just that the figcaption must be either the first child of the figure or the last child |
| 09:17 | <felixjet> | yeah, i realize thats the intent |
| 09:17 | <felixjet> | but why? |
| 09:17 | <felixjet> | is there a real reason behind than? |
| 09:17 | <MikeSmith> | yes |
| 09:17 | <felixjet> | rather than "its how it is" |
| 09:17 | <annevk> | I haven't really encountered a figure with a caption in the middle |
| 09:17 | <MikeSmith> | because the rest of the content is the figure |
| 09:17 | <MikeSmith> | right, what annevk said |
| 09:18 | <felixjet> | so even if figcaption is in the middle, the rest of the content can be the figure too |
| 09:18 | <felixjet> | :/ |
| 09:18 | <felixjet> | just like if you use <figcaption><pre><div><whatever> |
| 09:18 | <felixjet> | in this example, those 3 tags are the flow content |
| 09:18 | <annevk> | felixjet: if you have a good use case (bit more fleshed out than these markup examples) it might be worth filing a bug against the HTML Standard |
| 09:18 | <felixjet> | but <div><whatever><figcaption><pre>, it can not be? |
| 09:18 | <annevk> | felixjet: it's not unchangeable |
| 09:19 | <felixjet> | yeah, wanted to get some feedback then, in case there is a technical reason behind it |
| 09:20 | <MikeSmith> | the technical reason is that when as user looks at your figure, how to they tell what part of it is the caption? |
| 09:20 | <felixjet> | the <figcaption> |
| 09:20 | <felixjet> | and the rest is the figure |
| 09:20 | <MikeSmith> | how do users know what part is the figcaption? |
| 09:21 | <MikeSmith> | they don’t look at the source |
| 09:21 | <MikeSmith> | they look at how it is rendered |
| 09:21 | <felixjet> | how users know if the main content is a <main> tag, or just a <div>? |
| 09:21 | <MikeSmith> | and what users expect to see is a caption either above the figure or below the figure |
| 09:21 | <felixjet> | if they don't look at the source |
| 09:21 | <felixjet> | they just don't know |
| 09:22 | <MikeSmith> | sure they do, in teh case of figcaption |
| 09:22 | <felixjet> | the figure caption describes the figure |
| 09:22 | <felixjet> | so, the description, is the figcaption |
| 09:22 | <MikeSmith> | yeah |
| 09:22 | <felixjet> | i think people will know what a description is |
| 09:23 | <MikeSmith> | for users, the caption for a figure is either some text that is rendered just above the figure or just after the figure |
| 09:23 | <felixjet> | for example (maybe this is a retarded example, so sorry if it is) |
| 09:23 | <MikeSmith> | regardless of how it is marked up in the source, users look for the text before the figure or after the figure |
| 09:24 | <felixjet> | <figure><img src="duck.jpg"><figcaption>A duck dancing in the river</figcaption><time>2011-11</time></figure> |
| 09:24 | <felixjet> | what describes the figure? the figcaption of course |
| 09:24 | <felixjet> | and the time doesn't describe anything |
| 09:24 | <felixjet> | is not a description |
| 09:24 | <felixjet> | but it's part of the figure |
| 09:24 | <felixjet> | the picture and the time are related |
| 09:24 | <felixjet> | so why don't let people wrap that in a <figure>? |
| 09:24 | <felixjet> | to me, it makes sense |
| 09:25 | <MikeSmith> | I don’t understand how the <time> is part of the figure in that example |
| 09:25 | <felixjet> | and makes even more sense if you are using a div to apply styles |
| 09:26 | <felixjet> | which makes the figure a "figcaption followed by 1 flow content" |
| 09:26 | <felixjet> | MikeSmith, the time could be the date when the photo was taken |
| 09:26 | <felixjet> | it doesn't describe the photo |
| 09:26 | <felixjet> | so it can't be a caption |
| 09:27 | <MikeSmith> | seems like it does describe the photo actually |
| 09:27 | <MikeSmith> | but anyway as annevk said, if you think the spec should change you should raise an issue at https://github.com/whatwg/html/issues |
| 09:27 | <felixjet> | a description is a description in my opinion |
| 09:27 | <felixjet> | a date doesn't describe a duck |
| 09:27 | <felixjet> | but "the yellow duck dances by the river" is a description of the photo |
| 09:28 | <felixjet> | i'll file an issue so people can discuss |
| 09:28 | <MikeSmith> | in that example I don’t see how a user is supposed to know that 2011-11 means when the photo was taken |
| 09:28 | <felixjet> | Well, it was en example |
| 09:28 | <felixjet> | instead of <time> |
| 09:29 | <felixjet> | it could be: <div>Photo taken: <time>...</time></div> |
| 09:29 | <MikeSmith> | if/when you raise an issue I think you want to have a real example, a real use case |
| 09:29 | <felixjet> | my use case is really weird that probably someone will complain that is too retarded |
| 09:30 | <felixjet> | to me it makes sense ofc, but probably for others i'm missusing the tag |
| 09:30 | <MikeSmith> | well it may be odd but the spec is intended to cover odd use cases too if they are valid |
| 09:30 | <felixjet> | i'm using a <div> to indicate an API endpoint URL |
| 09:30 | <felixjet> | the figcaption to describe the figure |
| 09:31 | <felixjet> | and a <pre> tag to show the output of the API call |
| 09:31 | <felixjet> | the figcaption describes both the div and the pre tag |
| 09:31 | <MikeSmith> | btw please consider not using the word “retarded” the way you have been here. It’s an offensive term |
| 09:31 | <felixjet> | sorry, i use it as "stupid" |
| 09:31 | <MikeSmith> | so if that is your real use case then please include those details in the issue |
| 09:38 | <felixjet> | anyway, the spec also says |
| 09:38 | <felixjet> | > The figcaption element represents a caption or legend for the rest of the contents of the figcaption element's parent figure element, if any. |
| 09:38 | <felixjet> | "rest of the contents" |
| 09:38 | <felixjet> | thats plural |
| 09:39 | <felixjet> | figcaption being in the middle, could also mean that above, and below figcaption, all is related to the figure |
| 09:39 | <felixjet> | (just as an idea) |
| 09:40 | <annevk> | felixjet: I think though that if you use <time> in that way the <figcaption> wouldn't say anything about the <time> |
| 09:40 | <annevk> | felixjet: both <figcaption> and <time> would say something about the figure |
| 09:41 | <felixjet> | thats a good argument |
| 09:42 | <felixjet> | but only the first one |
| 09:42 | <felixjet> | not the second, since the time doesn't represent whats inside the picture at all |
| 09:45 | <felixjet> | but anyway i can't argue now hahga |
| 09:45 | <felixjet> | you have a point |
| 09:46 | <felixjet> | damn, you could have said it before, i have 90% of the issue done xD |
| 09:46 | <felixjet> | problem solved i guess, thanks |
| 09:49 | <annevk> | felixjet: allowing that would still require changes, so might as well file the issue |
| 09:58 | <felixjet> | how i'm supposed to file an issue without an example now >.< |
| 09:58 | <annevk> | felixjet: it's still a valid example |
| 09:58 | <annevk> | felixjet: since it still fails validation and maybe should not |
| 10:03 | <annevk> | I wonder if https://github.com/whatwg/html/issues/2441 is the first time Jens commented on a standard |
| 10:06 | <felixjet> | filed: https://github.com/whatwg/html/issues/2450 |
| 10:13 | <felixjet> | the <credit> one is a great argument in favor of sparse flow content |
| 10:21 | <MikeSmith> | oh wow jl |
| 10:23 | <MikeSmith> | felixjet: thanks for taking time to file that issue. Great issue description |
| 10:24 | <felixjet> | thank you for taking the time to give feedback :) |
| 11:00 | <zcorpan> | Using the string "null" as an origin was maybe not the greatest idea. See https://labs.detectify.com/2017/02/28/hacking-slack-using-postmessage-and-websocket-reconnect-to-steal-your-precious-token/ section Mitigation |
| 11:26 | <MikeSmith> | zcorpan: I think we should fix that by changing the CORS protocol so that a null origin never matches anything, equality comparison always fails |
| 11:26 | <MikeSmith> | the WebAppSec CORS section mentioned something about maybe the protocol will eventually change, so don’t rely on null matching forever |
| 11:26 | <zcorpan> | MikeSmith: CORS is not involved in window.postMessage |
| 11:27 | <MikeSmith> | ah hadn’t read the article yet :) |
| 11:27 | <MikeSmith> | as postMessage |
| 11:28 | <MikeSmith> | *ah it includes more and |
| 11:28 | <MikeSmith> | ofofs |
| 11:28 | MikeSmith | gives up on trying to type coherently for now |
| 11:55 | <mkwst> | zcorpan: It's doing a string comparison against "null", right? If so, it's not clear to me how they'd 'accept messages from the origin "null".' |
| 11:56 | <zcorpan> | mkwst: it doesn't |
| 11:56 | <zcorpan> | mkwst: it does if (!url) |
| 11:57 | <zcorpan> | which is probably dead code |
| 11:57 | <mkwst> | Ah. Yeah. That's not going to work. |
| 11:58 | <mkwst> | I see. `a.src = "null"` resolves against the local document, which breaks their comparison. |
| 11:59 | <mkwst> | Well, I wouldn't be terribly sad if we changed postmessage to send `null` rather than `"null"`, but I suspect that's going to be difficult to change at this point. |
| 12:00 | <zcorpan> | changing it would introduce a problem for anyone who checks for the string "null" |
| 12:00 | <mkwst> | Exactly. |
| 14:54 | <annevk> | mkwst: just keep saying no to versioning btw, even if a bunch of folks tell you it's a good idea |
| 14:54 | <mkwst> | Yeah, I think the costs are pretty high. |
| 14:56 | <annevk> | We're still cleaning up the last time browsers decided to add a giant branch in their code |
| 14:57 | <mkwst> | I'll ping you if people say they totally need it. |
| 14:57 | <mkwst> | Until then, I'm not actually planning on ever writing a CSP4, so... |
| 15:02 | <annevk> | You'll have to keep maintaining CSP though, but if you're rejecting all new features that should be easier |
| 15:03 | <mkwst> | Naah, CSP3 is perfect. No maintenance necessary! Just don't ever change Fetch or HTML, plz. |
| 15:03 | <mkwst> | :) |
| 15:04 | <annevk> | sure |
| 16:43 | <domfarolino> | If by default, the credentials mode of fetch is `omit`, is there a situation where you'd ever need to explicitly specify `{credentials: 'omit'}`? |
| 17:42 | <annevk> | domfarolino: if you pass in a request object |
| 17:42 | <annevk> | domfarolino: it's a fallback default only used when the first argument is a string, iirc |
| 18:15 | <domfarolino> | annevk: it looks like a request object's default credentials property is "omit" (new Request().credentials yields "omit") which kinda does the explicit work for you. |
| 18:17 | <domfarolino> | annevk: I guess just passing {credentials: 'omit'} explicitly is added security or something |
| 18:20 | <annevk> | domfarolino: if you do new Request(existingRequest).credentials it isn't necessarily "omit" is what I'm saying |
| 18:21 | <domfarolino> | annevk: Ohh sorry, that makes sense thanks :) |
| 18:23 | <zcorpan> | Soooooo.... anyone think we should keep https://html-differences.whatwg.org/ alive and is interested enough to take over as editor? See https://github.com/whatwg/html-differences/issues/2 |
| 18:25 | <zcorpan> | (A sort-of benefit from converting this document to bikeshed would be that HTML needs to more consistently export all elements and attributes etc.) |
| 18:31 | <zcorpan> | Also see https://github.com/whatwg/html-differences/pull/4 |
| 18:34 | <jsbell> | annevk: if I can review any more test/spec PRs for you please ping (if github has a task list UI other than notifications it is well hidden) |
| 18:35 | <jgraham> | jsbell: Oh, annevk showed me this the other day |
| 18:35 | <annevk> | jsbell: there's https://github.com/pulls/review-requested but currently nothing outstanding I think |
| 18:35 | <jgraham> | It is well hidden! |
| 18:36 | <jsbell> | thx! |
| 18:36 | <annevk> | jsbell: someone noticed storage/interfaces.html might have to be renamed to https.html but I'm still awaiting answer on whether they want to land that Gecko side or have me do it |
| 18:37 | <annevk> | jsbell: and I'm also trying to figure out whether it would make sense to start using .any.js for more encoding/ tests or whether that would be somewhat bad money/resources wise |
| 18:38 | <jsbell> | I hadn't been aware of .any.js tests before; let me see if we even run them in blink... |
| 18:38 | <annevk> | (until yesterday we didn't have a single worker test it seemed) |
| 18:38 | <annevk> | jsbell: hmm I guess the idlharness test is also out-of-date |
| 18:48 | <jsbell> | Doesn't look like we run the .any.js tests in Blink yet, still digging though. |
| 18:48 | <gsnedders> | and .worker.js? |
| 18:49 | <gsnedders> | Both rely on wptserve, so I think they were previously not being run until that got enabled and stuck |
| 18:50 | <jsbell> | Do not seem to, but there's a chance I'm invoking wrong. wptserve is is enabled and stuck. Maybe I'm doing something wrong and/or we are missing some plumbing and/or we incorrectly filter them out... |
| 18:50 | <gsnedders> | Yeah, I know it's stuck. It's just maybe nobody has actually done it now it has stuck. :) |
| 18:56 | <jsbell> | Okay, known issue at least: https://crbug.com/653514 - I'll upvote/check status/etc |
| 21:55 | <KiChjang> | i need some help in understanding MessagePorts |
| 21:55 | <KiChjang> | https://html.spec.whatwg.org/multipage/comms.html#messageport |
| 21:56 | <KiChjang> | what happens to the tasks when the has_been_shipped flag is unset? |
| 21:56 | <KiChjang> | and similarly, what happens to the tasks when the port is disabled? |
| 21:56 | <KiChjang> | are they ever dropped? |