freenode :: #whatwg

20 Mar 2017
08:13annevkzcorpan: technically was not editorial, existing text would result in a compile error I think
08:17annevkI do like your use of the Unicode arrow, I should try to find it next time I have something like this
09:03felixjetcan someone give me a hand?
09:03felixjetthe validator is trolling me
09:03felixjetError: Element pre not allowed as child of element figure in this context.
09:04felixjetContexts in which element pre may be used: --> Where flow content is expected.
09:04felixjetright. so i can only use <pre> where flow content is expected
09:04felixjetContent model for element figure: --> Flow content optionally including a figcaption child element.
09:04felixjetso..... wt*
09:04felixjetfigure accepts flow content
09:04felixjetand <pre> must be used where flow content is expected
09:04felixjetwhats going wrong here?
09:10annevkfelixjet: I&#39;d file a bug
09:10felixjetso i have nothing wrong here?
09:10felixjetin case it matters
09:10felixjetmy structure is:
09:11felixjetmaybe i can&#39;t use div AND pre?
09:11felixjetbut the spec doesn&#39;t say anything about how many flow content elements are valid
09:11MikeSmiththe spec says thats not valid
09:12MikeSmithContent model:
09:12MikeSmithEither: One figcaption element followed by flow content.
09:12MikeSmithOr: Flow content followed by one figcaption element.
09:12MikeSmithOr: Flow content.
09:12felixjetit just say:
09:12felixjetContent model: -> Either: One figcaption element followed by flow content.
09:12MikeSmithwhich spec?
09:12felixjeti just copied what you just said
09:12felixjetso <div></div><pre></pre> is not &quot;flow content&quot; ?
09:13MikeSmith<div></div><figcaption></figcaption><pre></pre> is not One figcaption element followed by flow content
09:13felixjetwhy the order does matter?
09:13MikeSmiththat is flow content followed by figcaption followed by flow content
09:13felixjetwhat if figcaption is in the middle?
09:13MikeSmithyeah, that
09:13felixjeti mean, why thats now allowed?
09:14MikeSmithbecause that is what the spec requires
09:14felixjetbut maybe is spec&#39;ed like that because none was thinking about using multiple flow content inside figure
09:14felixjetbut there shouldn&#39;t be any limitation to do so
09:14felixjeti&#39;m wrong?
09:15MikeSmithit was specified that way intentionally, it is not an oversight
09:15MikeSmiththe intent is just that the figcaption must be either the first child of the figure or the last child
09:16felixjeti was using the div to create a title, the figcaption to describe the figure, and <pre> is the figure itself
09:16felixjetbut <figcaption><div><pre> is allowed?
09:16felixjetso... why in me middle is forbidden?
09:16felixjetin the*
09:16felixjettheres a real reason?
09:16MikeSmithbecause as I said, the intent is just that the figcaption must be either the first child of the figure or the last child
09:17felixjetyeah, i realize thats the intent
09:17felixjetbut why?
09:17felixjetis there a real reason behind than?
09:17felixjetrather than &quot;its how it is&quot;
09:17annevkI haven&#39;t really encountered a figure with a caption in the middle
09:17MikeSmithbecause the rest of the content is the figure
09:17MikeSmithright, what annevk said
09:18felixjetso even if figcaption is in the middle, the rest of the content can be the figure too
09:18felixjetjust like if you use <figcaption><pre><div><whatever>
09:18felixjetin this example, those 3 tags are the flow content
09:18annevkfelixjet: 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:18felixjetbut <div><whatever><figcaption><pre>, it can not be?
09:18annevkfelixjet: it&#39;s not unchangeable
09:19felixjetyeah, wanted to get some feedback then, in case there is a technical reason behind it
09:20MikeSmiththe technical reason is that when as user looks at your figure, how to they tell what part of it is the caption?
09:20felixjetthe <figcaption>
09:20felixjetand the rest is the figure
09:20MikeSmithhow do users know what part is the figcaption?
09:21MikeSmiththey dont look at the source
09:21MikeSmiththey look at how it is rendered
09:21felixjethow users know if the main content is a <main> tag, or just a <div>?
09:21MikeSmithand what users expect to see is a caption either above the figure or below the figure
09:21felixjetif they don&#39;t look at the source
09:21felixjetthey just don&#39;t know
09:22MikeSmithsure they do, in teh case of figcaption
09:22felixjetthe figure caption describes the figure
09:22felixjetso, the description, is the figcaption
09:22felixjeti think people will know what a description is
09:23MikeSmithfor users, the caption for a figure is either some text that is rendered just above the figure or just after the figure
09:23felixjetfor example (maybe this is a retarded example, so sorry if it is)
09:23MikeSmithregardless of how it is marked up in the source, users look for the text before the figure or after the figure
09:24felixjet<figure><img src=&quot;duck.jpg&quot;><figcaption>A duck dancing in the river</figcaption><time>2011-11</time></figure>
09:24felixjetwhat describes the figure? the figcaption of course
09:24felixjetand the time doesn&#39;t describe anything
09:24felixjetis not a description
09:24felixjetbut it&#39;s part of the figure
09:24felixjetthe picture and the time are related
09:24felixjetso why don&#39;t let people wrap that in a <figure>?
09:24felixjetto me, it makes sense
09:25MikeSmithI dont understand how the <time> is part of the figure in that example
09:25felixjetand makes even more sense if you are using a div to apply styles
09:26felixjetwhich makes the figure a &quot;figcaption followed by 1 flow content&quot;
09:26felixjetMikeSmith, the time could be the date when the photo was taken
09:26felixjetit doesn&#39;t describe the photo
09:26felixjetso it can&#39;t be a caption
09:27MikeSmithseems like it does describe the photo actually
09:27MikeSmithbut anyway as annevk said, if you think the spec should change you should raise an issue at
09:27felixjeta description is a description in my opinion
09:27felixjeta date doesn&#39;t describe a duck
09:27felixjetbut &quot;the yellow duck dances by the river&quot; is a description of the photo
09:28felixjeti&#39;ll file an issue so people can discuss
09:28MikeSmithin that example I dont see how a user is supposed to know that 2011-11 means when the photo was taken
09:28felixjetWell, it was en example
09:28felixjetinstead of <time>
09:29felixjetit could be: <div>Photo taken: <time>...</time></div>
09:29MikeSmithif/when you raise an issue I think you want to have a real example, a real use case
09:29felixjetmy use case is really weird that probably someone will complain that is too retarded
09:30felixjetto me it makes sense ofc, but probably for others i&#39;m missusing the tag
09:30MikeSmithwell it may be odd but the spec is intended to cover odd use cases too if they are valid
09:30felixjeti&#39;m using a <div> to indicate an API endpoint URL
09:30felixjetthe figcaption to describe the figure
09:31felixjetand a <pre> tag to show the output of the API call
09:31felixjetthe figcaption describes both the div and the pre tag
09:31MikeSmithbtw please consider not using the word retarded the way you have been here. Its an offensive term
09:31felixjetsorry, i use it as &quot;stupid&quot;
09:31MikeSmithso if that is your real use case then please include those details in the issue
09:38felixjetanyway, the spec also says
09:38felixjet> The figcaption element represents a caption or legend for the rest of the contents of the figcaption element&#39;s parent figure element, if any.
09:38felixjet&quot;rest of the contents&quot;
09:38felixjetthats plural
09:39felixjetfigcaption being in the middle, could also mean that above, and below figcaption, all is related to the figure
09:39felixjet(just as an idea)
09:40annevkfelixjet: I think though that if you use <time> in that way the <figcaption> wouldn&#39;t say anything about the <time>
09:40annevkfelixjet: both <figcaption> and <time> would say something about the figure
09:41felixjetthats a good argument
09:42felixjetbut only the first one
09:42felixjetnot the second, since the time doesn&#39;t represent whats inside the picture at all
09:45felixjetbut anyway i can&#39;t argue now hahga
09:45felixjetyou have a point
09:46felixjetdamn, you could have said it before, i have 90% of the issue done xD
09:46felixjetproblem solved i guess, thanks
09:49annevkfelixjet: allowing that would still require changes, so might as well file the issue
09:58felixjethow i&#39;m supposed to file an issue without an example now >.<
09:58annevkfelixjet: it&#39;s still a valid example
09:58annevkfelixjet: since it still fails validation and maybe should not
10:03annevkI wonder if is the first time Jens commented on a standard
10:13felixjetthe <credit> one is a great argument in favor of sparse flow content
10:21MikeSmithoh wow jl
10:23MikeSmithfelixjet: thanks for taking time to file that issue. Great issue description
10:24felixjetthank you for taking the time to give feedback :)
11:00zcorpanUsing the string &quot;null&quot; as an origin was maybe not the greatest idea. See section Mitigation
11:26MikeSmithzcorpan: I think we should fix that by changing the CORS protocol so that a null origin never matches anything, equality comparison always fails
11:26MikeSmiththe WebAppSec CORS section mentioned something about maybe the protocol will eventually change, so dont rely on null matching forever
11:26zcorpanMikeSmith: CORS is not involved in window.postMessage
11:27MikeSmithah hadnt read the article yet :)
11:27MikeSmithas postMessage
11:28MikeSmith*ah it includes more and
11:28* MikeSmith gives up on trying to type coherently for now
11:55mkwstzcorpan: It&#39;s doing a string comparison against &quot;null&quot;, right? If so, it&#39;s not clear to me how they&#39;d &#39;accept messages from the origin &quot;null&quot;.&#39;
11:56zcorpanmkwst: it doesn&#39;t
11:56zcorpanmkwst: it does if (!url)
11:57zcorpanwhich is probably dead code
11:57mkwstAh. Yeah. That&#39;s not going to work.
11:58mkwstI see. `a.src = &quot;null&quot;` resolves against the local document, which breaks their comparison.
11:59mkwstWell, I wouldn&#39;t be terribly sad if we changed postmessage to send `null` rather than `&quot;null&quot;`, but I suspect that&#39;s going to be difficult to change at this point.
12:00zcorpanchanging it would introduce a problem for anyone who checks for the string &quot;null&quot;
14:54annevkmkwst: just keep saying no to versioning btw, even if a bunch of folks tell you it&#39;s a good idea
14:54mkwstYeah, I think the costs are pretty high.
14:56annevkWe&#39;re still cleaning up the last time browsers decided to add a giant branch in their code
14:57mkwstI&#39;ll ping you if people say they totally need it.
14:57mkwstUntil then, I&#39;m not actually planning on ever writing a CSP4, so...
15:02annevkYou&#39;ll have to keep maintaining CSP though, but if you&#39;re rejecting all new features that should be easier
15:03mkwstNaah, CSP3 is perfect. No maintenance necessary! Just don&#39;t ever change Fetch or HTML, plz.
16:43domfarolinoIf by default, the credentials mode of fetch is `omit`, is there a situation where you&#39;d ever need to explicitly specify `{credentials: &#39;omit&#39;}`?
17:42annevkdomfarolino: if you pass in a request object
17:42annevkdomfarolino: it&#39;s a fallback default only used when the first argument is a string, iirc
18:15domfarolinoannevk: it looks like a request object&#39;s default credentials property is &quot;omit&quot; (new Request().credentials yields &quot;omit&quot;) which kinda does the explicit work for you.
18:17domfarolinoannevk: I guess just passing {credentials: &#39;omit&#39;} explicitly is added security or something
18:20annevkdomfarolino: if you do new Request(existingRequest).credentials it isn&#39;t necessarily &quot;omit&quot; is what I&#39;m saying
18:21domfarolinoannevk: Ohh sorry, that makes sense thanks :)
18:23zcorpanSoooooo.... anyone think we should keep alive and is interested enough to take over as editor? See
18:25zcorpan(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:31zcorpanAlso see
18:34jsbellannevk: 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:35jgrahamjsbell: Oh, annevk showed me this the other day
18:35annevkjsbell: there&#39;s but currently nothing outstanding I think
18:35jgrahamIt is well hidden!
18:36annevkjsbell: someone noticed storage/interfaces.html might have to be renamed to https.html but I&#39;m still awaiting answer on whether they want to land that Gecko side or have me do it
18:37annevkjsbell: and I&#39;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:38jsbellI hadn&#39;t been aware of .any.js tests before; let me see if we even run them in blink...
18:38annevk(until yesterday we didn&#39;t have a single worker test it seemed)
18:38annevkjsbell: hmm I guess the idlharness test is also out-of-date
18:48jsbellDoesn&#39;t look like we run the .any.js tests in Blink yet, still digging though.
18:48gsneddersand .worker.js?
18:49gsneddersBoth rely on wptserve, so I think they were previously not being run until that got enabled and stuck
18:50jsbellDo not seem to, but there&#39;s a chance I&#39;m invoking wrong. wptserve is is enabled and stuck. Maybe I&#39;m doing something wrong and/or we are missing some plumbing and/or we incorrectly filter them out...
18:50gsneddersYeah, I know it&#39;s stuck. It&#39;s just maybe nobody has actually done it now it has stuck. :)
18:56jsbellOkay, known issue at least: - I&#39;ll upvote/check status/etc
21:55KiChjangi need some help in understanding MessagePorts
21:56KiChjangwhat happens to the tasks when the has_been_shipped flag is unset?
21:56KiChjangand similarly, what happens to the tasks when the port is disabled?
21:56KiChjangare they ever dropped?
21 Mar 2017
No messages
Last message: 154 days and 19 hours ago