| 07:14 | <annevk> | MikeSmith: yeah, topics make sense |
| 07:42 | <yoav> | zcorpan: thoughts on https://github.com/whatwg/fetch/pull/437 ? |
| 07:45 | <zcorpan> | yoav: I'm OK with separating video and audio. But I would be interested in when/where they diverge in the network stack in implementations later |
| 07:57 | <yoav> | zcorpan: currently they're the same resource type internally in Chrome |
| 07:57 | <yoav> | but I guess that may change in the future, and not sure that's true for all browsers |
| 09:34 | <MikeSmith> | the HTML used to day the `defer` must not be specified for `script` elements that don’t also have a `src` attribute |
| 09:35 | <MikeSmith> | I guess we changed that? |
| 09:35 | <annevk> | MikeSmith: not intentionally, I think |
| 09:38 | <MikeSmith> | oh OK |
| 09:38 | <MikeSmith> | will ping Domenic about it then |
| 10:12 | <zcorpan> | MikeSmith: seems like a regression introduced by <script type=module> |
| 10:12 | <MikeSmith> | yeah |
| 10:12 | <MikeSmith> | will raise a PR for it |
| 10:13 | <MikeSmith> | https://github.com/whatwg/html/commit/cd1a9fb1e83f7d0bc30be8b34ecdaf444a0b19a4#diff-36cd38f49b9afa08222c0dc9ebfe35ebL59339 |
| 10:14 | <MikeSmith> | caught by having just happened to look back at an old Stackoverflow question http://stackoverflow.com/questions/38291503/code-defer-not-w3-valid/42622772#42622772 |
| 10:19 | <MikeSmith> | in other news also just noticed this new (CSS) question: https://stackoverflow.com/questions/42622197/were-there-any-technical-limitations-within-css-that-led-to-the-decision-of-usin |
| 10:19 | <MikeSmith> | “Were there any technical limitations within CSS that led to the decision of using `--` for vars?” |
| 10:47 | <annevk> | Hmm, did Bikeshed regress again? |
| 10:47 | <annevk> | Builds are failing again |
| 10:47 | <annevk> | Hmm indeed |
| 10:47 | <annevk> | FATAL ERROR: 'Default Biblio Status' must be either 'current' or 'snapshot'. Got 'current' |
| 10:48 | <annevk> | after updating Bikeshed locally |
| 10:48 | <annevk> | fuck |
| 10:48 | <annevk> | (sorry) |
| 10:50 | annevk | files https://github.com/tabatkins/bikeshed/issues/941 |
| 10:50 | <annevk> | It's really rather scary how unstable Bikeshed is |
| 10:51 | <annevk> | And I doubt anyone verifies the actual output much other than folks that occasionally read the standard |
| 10:51 | <annevk> | Still not entirely sure it's a win over Anolis |
| 11:01 | <csarven> | The ordering of the elements in table is not so fun here: https://www.w3.org/TR/html/tabular-data.html#the-table-element and https://www.w3.org/TR/html5/tabular-data.html#the-table-element .. in particular to tfoot appearing before tbody. https://www.w3.org/TR/html401/struct/tables.html#h-11.2.3 required tfoot before tbody |
| 11:02 | <annevk> | I'm not sure what is not fun |
| 11:02 | <csarven> | https://www.w3.org/wiki/HTML/W3C-WHATWG-Differences doesn't mention the differences. |
| 11:02 | <annevk> | OR what you're trying to say, rather |
| 11:03 | <annevk> | csarven: https://html-differences.whatwg.org/#content-model lists it |
| 11:03 | <csarven> | Perhaps I'm misinterpreting TR/html/ but it seems to be that tfoot can't come before tbody? |
| 11:04 | <annevk> | csarven: doesn't it say that it can? |
| 11:08 | <csarven> | https://www.w3.org/TR/html/tabular-data.html ? It doesn't seem like it. Again, perhaps I'm overlooking a wording here. |
| 11:08 | <csarven> | re: https://html-differences.whatwg.org/#content-model hints at the possibility "The table element now allows the tfoot element to be the last child." |
| 11:09 | <csarven> | I just wanted a clarification. I'm okay to only use it after tbody but earlier publications used tfoot before tbody and was wondering whether that's still "okay" as far as HTML5 is concerned. |
| 11:16 | <annevk> | Hmm I guess you're right |
| 11:16 | <annevk> | I don't really know anything about fork HTML though |
| 11:16 | <annevk> | Well, I know some things, such as that it contains bugs and that it's rather poorly maintained |
| 12:01 | <yoav> | annevk: If I read https://github.com/whatwg/fetch/issues/355 correctly, it is still possible to handle opaque responses as a stream. Is that correct? |
| 12:03 | <annevk> | yoav: a non-exposed stream, yes |
| 12:11 | <yoav> | annevk: ok, cool |
| 13:00 | <annevk> | hendry: re Twitter it's a little unclear to me what you're trying to do |
| 13:00 | <annevk> | hendry: do you want to display PDF inside an <iframe> or some such? |
| 13:01 | <annevk> | hendry: if you want to display the PDF using standards you'd need https://github.com/mozilla/pdf.js |
| 14:16 | <zcorpan> | yoav: the commit message still talks about `Accept`...? |
| 14:17 | <yoav> | I can remove that part |
| 15:49 | <Domenic> | Yeah Bikeshed woes are not great |
| 15:50 | <Domenic> | The fact that the build is red half the time according to https://github.com/tabatkins/bikeshed/commits/master does not inspire confidence that the changes are tested locally before pushing |
| 15:50 | <Domenic> | and commits that fix something but don't add a new test to prevent regressions are scary |
| 15:51 | <Domenic> | but i guess if the tests mostly don't pass them it's harder to add new tests |
| 15:51 | <TabAtkins> | Yeah, sorry about this. It was a big refactoring job that I assumed didn't need extra testing. 😑 |
| 15:51 | <TabAtkins> | Tests almost always go red for trivial rebasing reasons |
| 15:51 | <Domenic> | doesn't mean they shouldn't be fixed before pushing |
| 15:52 | <TabAtkins> | Yeah, you're right. When people were usually pulling Bikeshed manually or was okay to let Travis catch failures, but I need to be more disciplined about catching them before I push, not 30 minutes later. |
| 16:02 | <TabAtkins> | But also: seriously wtf is this damn error about. |
| 16:03 | <TabAtkins> | I switched biblio/ref status from being a plain string to being an enum, and it's claiming one of the enum values isn't in the enum. :( |
| 16:20 | <Domenic> | my guess was that in the 'x' is not an 'x', one of the 'x's is an enum and the other is a string |
| 16:26 | <TabAtkins> | No, that's fine. Finally tracked it down, pushing now. |
| 16:28 | <TabAtkins> | I'd tested `"foo" in enum` and `foo["enum"]`, and foolishly assumed that `foo(enum)`, which *appeared* be the identical to using square braces except it allowed enum instances, would do the same. |
| 16:28 | <TabAtkins> | (Sorry, enum["foo"] and enum("foo").) |
| 16:29 | <TabAtkins> | The calling syntax instead does a *by value* search, and the enum are auto-numbered by default, so their value was an int, not a string. :( |
| 16:30 | <TabAtkins> | This enum class is supposedly matching the enum PEP, but jeezus it's kinda shitty for what feels like standard-ass usage. |
| 16:42 | <Domenic> | Great :). Hope the fix commit includes a test to prevent future regressions! |
| 16:42 | <TabAtkins> | Will in a sec, was pushing the fix first after testing it locally. ^_^ |
| 17:02 | <annevk> | hurray |
| 19:12 | <MikeSmith> | csarven: https://github.com/whatwg/html/commit/94d55af9cda601ce675d15f6a0e52c9bb9c6afa9 |
| 19:13 | <MikeSmith> | csarven: from https://github.com/whatwg/html/issues/352 |
| 19:13 | <MikeSmith> | > In HTML4, `tfoot` had to appear before `tbody`, but HTML5 allowed either before or after. Placing it before causes problems for keyboard focus order and order of accessibility objects, so this changes the content model to no longer allow `tfoot` before `tbody`. |
| 20:12 | <csarven> | MikeSmith Thanks for that! |
| 20:13 | <csarven> | My intuition as to why tfoot was suggested to go before tbody was also so that legend-like info can be read/interpreted before looking at the tbody. |
| 20:13 | <csarven> | But if that was really the case, I would expect tfoot come even before thead |
| 20:14 | <csarven> | Any way.. good to have context for the current state of the spec |
| 20:14 | <csarven> | I use tfoot all the time. And before tbody. Doing that out of old habit re HTML 4.01. |
| 20:15 | <csarven> | Will update. |
| 20:28 | <KiChjang> | is "refactoring the web" pretty much well-nigh impossible without causing a lot of breakage, angry protests and churn? |
| 20:32 | <Domenic> | Well, by at least some definitions, refactoring literally means no changes to observable behavior, so it should be fine |
| 23:58 | <jsbell> | Domenic: dom.spec.whatwg.org hasn't picked up the latest commit; something broken or need poking, or am I missing something (as usual...) ? |