freenode :: #whatwg

17 Jan 2017
08:08annevkI feel somewhat conflicted with whether to respond to
08:09annevkIt seems like publishing a WD that's essentially the same as the broken REC will waste a lot of folks their time looking through it
10:43No_seHello! Are you running the Nu Html checker service on
10:44No_seI just created an issue on github and wonder if I got the markup right.
10:53Ms2gerMikeSmith, ^
10:58No_seAfter simply copy pasting from the github issue into the validator: Nvm the markup question. Just worry about the issue ;-)
11:03hsivonenso hard to write commit messages without a trailing period for the WHATWG when m-c has taught me to use a trailing period
11:14zcorpan_hsivonen: you can let the merger worry about the commit message :-)
11:14hsivonenzcorpan_: ok
11:35MikeSmithNo_se: yeah I run the W3C instance of the Nu Html Checker
11:35MikeSmithNo_se: do you mean
11:36No_seI can give a live URL with the issue, if that's faster than my minimal example
11:36No_se but you do not want to look at that code...
11:37MikeSmithwell regardless the answer is that the checker is behaving as expected
11:37MikeSmithyou can&#39;t put a <ul> tag as a child if a <p> tag in your markup
11:38MikeSmithit will not end up in the DOM that way after parsing
11:38No_seSorry fir the noise then. Gonna check the spec again
11:38MikeSmithwell this is not completely obvious from the spec
11:38MikeSmithit causes confusion regularly
11:39MikeSmithand the error message from the checker for this case it not very helpful
11:40MikeSmithbut what happens is, the parser closes that <p> element in the DOM before it starts the <ul> element
11:41No_seSo, giving a message at opening the <p> woud be the way to go for the validator?
11:41MikeSmithso then later when it comes across the closing </p> tag after the <ul> element, it says No p element in scope but a p end tag seen
11:41MikeSmithwe cant easily make the checker emit an additional message in this case
11:42MikeSmithwell we could but it would add unnecessary noise for other normal cases
11:42MikeSmithbecause closing </p> tags are not required in many normal cases
11:42MikeSmithwell even a lot of people would consider this <p><ul> a normal case
11:43MikeSmiththey would just not have a closing </p> anywhere in their markup in that case
11:44MikeSmitharguably you can make your life easier by not using closing </p> tags anywhere
11:44MikeSmithnot closing </li> tags or others that arent strictly required
11:45No_seSo consider <p> similar as <br /> and be done with it?
11:45MikeSmiththat is what I do personally
11:45MikeSmiththat is was <p> was originally when HTML was created
11:46AutomatedTesterwhat is the state of web components these days?
11:46MikeSmithit was defined as a paragraph break when it was created
11:46MikeSmithNo_se: the notiion of the p element being a container was something bolted on later
11:47MikeSmithNo_se: anyway, others would disagree with me about whether you should use </p> end tags or not
11:47MikeSmithAutomatedTester: supported quite well in Blink and WebKit
11:48AutomatedTesterMikeSmith: ok, and the spec is &quot;stable&quot; ?
11:48MikeSmithyes, stable
11:49MikeSmithApple and Google have gotten past the previous big disagreements they had, and what is in the spec now represents strong consensus
11:50MikeSmithmodulo normal open issues where discussion is still going on
11:50AutomatedTesteryea, I last heard about the disagreements and wasnt sure if they had been cleared up and if the spec was close to what was agreed
11:50MikeSmithand Mozilla and Microsoft also supportive of current spec, and actively worked on getting it made
11:50AutomatedTesterMikeSmith: thank you!
12:01hsivonenis &quot;dismiss review&quot; the right UI to use for indicating that all issues in the review have been addressed?
12:02hsivonendoesn&#39;t sound like it but that UI removes the red X
12:07Ms2gerIt&#39;s what I use; possibly the intended workflow is that the reviewers does a new review that&#39;s marked as approved
12:11annevkYeah I think the reviewer can hit approve
12:11annevkOr dismiss themselves
12:41zcorpanMikeSmith: the real paragraph break is to always use </p>, never <p> :-D
12:42zcorpanNo_se: not using an initial <p> or a <p> after a list or a table seems like it would give less control or unexpected results with styling
12:44zcorpanlike p { margin: 2em 0 } would not apply the extra spacing to text not in p
13:51MikeSmithannevk: so I made some changes to the MDN HTTP access control (CORS) both to add a note about the WebKit non-standard header-values thing and also to fix some other inaccuracies and bring it closer in sync with the current spec
13:52annevkMikeSmith: cool
13:55MikeSmithannevk: if you have time to sanity-check the changes, the content is in the section and in the
13:56MikeSmithand the info is essentially duplicated in those sections
13:56* annevk looks
13:57MikeSmithbut that duplication is because, from seeing Stackoverflow questions, some people read one of those sections but not the other
13:57annevkMikeSmith: I kinda dislike we still call them &quot;preflight requests&quot; although I guess they don&#39;t really have a name anymore in Fetch
13:58MikeSmithFetch also does not have simple requests
13:58annevksorry, that&#39;s what I meant
13:58MikeSmithyeah I am reluctant to change that right now at least
13:58annevkpreflight requests are still a thing, it&#39;s simple requests that&#39;s kinda wrongish
13:58MikeSmithbut that section is linked to in quite a lot of places I think
13:58annevkconditions look okay from a quick skim
13:59hsivonenas seen in zcorpan&#39;s review of my PR, Python&#39;s narrow vs. wide build distinction is even worse than I thought
13:59annevkYeah I ran into that when writing IDNA tests
14:00annevkPython is rather terrible when it comes to Unicode
14:04annevkhsivonen: I might be able to look later today again, but might take a little longer today
14:04annevkhsivonen: kid was unexpectedly sick
14:04hsivonenno hurry
14:15MikeSmithannevk: is there actually any equivalent term for simple request in the current Fetch spec?
14:20MikeSmithoh I see you said earlier, although I guess they don&#39;t really have a name anymore in Fetch
14:27Ms2gerAn interesting find:
14:28MikeSmithholy god
14:30* MikeSmith clones a copy before it disappears
14:45zcorpanhsivonen: per a possibility would be to switch to 3.3
16:03wanderviewannevk: I updated the doodle for the fetch meeting, but unfrotunately my schedule is not very flexible due to taking my kids to school in the monring
16:03wanderviewfeel free to schedule without me if that makes sense
16:27annevkwanderview: the doodle isn&#39;t flexible for similar reasons, hopefully it&#39;ll work out
16:28wanderviewwell, I noticed I am the exact opposite time availability with other people on there :-\
16:38annevkFor Chrome bugs, is there a URL to file a new one that puts it in Blink triage? rbyers, maybe you know?
16:40Domenicannevk: mostly it&#39;s a matter of adding appropriate components. Does your UI allow that?
16:40DomenicIf not we should probably add you to some list that does.
16:42annevkDomenic: I can, but looking to reduce clicks
16:43annevkDomenic: and not forgetting about it
16:44DomenicHmm I see. Maybe there is a URL that pre-fills form fields but that&#39;ll always have the disadvantage of requiring an extra round of triage: Blink -> more specific component via human triage -> actual owner
16:45DomenicSeems ideal if you can figure out the more specific component yourself so it gets routed to the appropriate team immediately instead of going through the first round
17:03gsneddersMikeSmith: I presume you have no intention to extend to check CSS too?
17 Jan 2017
Last message: 11 minutes ago