| 00:02 | <MikeSmith> | tantek: the outline algorithm is a consequence of having added <section> and <article> that can be nested to arbitrary depth with <h1> headings |
| 00:02 | <MikeSmith> | so some mechanism is needed to determine what actual level and <h1> is at in the hierarchy |
| 00:03 | <MikeSmith> | in particular, for screen-reader users |
| 00:03 | <tantek> | or nothing actually cares in practice about "what actual level..." so no browser ever bothered to implement it |
| 00:03 | <MikeSmith> | screen-reader users care |
| 00:03 | <tantek> | and the screen-reader excuse doesn't cut it either |
| 00:04 | <tantek> | because experience has shown anything not implemented in browsers, but supposedly implemented / needed by a screen-reader, will be unreliable at best, possibly deceptive |
| 00:04 | <tantek> | e.g. longdesc |
| 00:04 | <MikeSmith> | well otherwise all those <h1>s get presented to screen-reader users as top-level headings |
| 00:04 | <tantek> | also the outline algorithm is classic aspirational design |
| 00:04 | <tantek> | doomed to failure |
| 00:05 | <tantek> | not sure why anyone is still hanging onto it. |
| 00:05 | <tantek> | the claims of needs are all circular |
| 00:05 | <MikeSmith> | man the matter-of-fact way you have of stating everything in IRC discussions does not invite enthusiasm about trying to have any kind of online conversation with you |
| 00:06 | <MikeSmith> | do you have any idea how annoying it is to be on the receiving end of that? |
| 00:07 | <tantek> | MikeSmith, yeah I realize it is not necessarily the most productive |
| 00:07 | <tantek> | more ventful for sure |
| 00:08 | <tantek> | the problem is that outline algo smells more like appcache than like say, audio or video |
| 00:08 | <MikeSmith> | yeah agreed it’s not our finest hour |
| 00:09 | <tantek> | and frankly I'd rather not see "us" hang on to it as long as we hung onto appcache |
| 00:09 | <MikeSmith> | and it’s something web developers mostly don’t need to care about |
| 00:09 | <tantek> | now you sound like you're describing longdesc |
| 00:09 | <tantek> | similar behavior flaw of the advocates hanging onto for too long IMO |
| 00:09 | <tantek> | we're not very good about admitting when things seem to be failing / have failed, ditch them, and come up with alternatives later (using lessons learned) |
| 00:10 | <MikeSmith> | I think the outline algorithm is way different from longdesc to the point that comparison is a non sequitur |
| 00:10 | <MikeSmith> | this is not a case of hanging on to something because anybody is advocating for it |
| 00:11 | <tantek> | MikeSmith, fair. example: web developers using <section> and <h1> etc. based on the impacts (or lack thereof) in browsers, not caring (not knowing) at all |
| 00:11 | <tantek> | about any impacts on the outline algorithm |
| 00:11 | <MikeSmith> | right |
| 00:11 | <tantek> | = noise into the algo |
| 00:11 | <tantek> | that's the analogy to longdesc |
| 00:11 | <tantek> | though with longdesc you have to bother to actually type the attribute in |
| 00:11 | <tantek> | and then think, oh, long description, sure I'll type a bunch of text here |
| 00:12 | <tantek> | and then get it wrong (since it's supposed to be a URL only) |
| 00:12 | <MikeSmith> | yeah |
| 00:12 | <tantek> | it's a coarse analogy to be sure |
| 00:12 | <tantek> | but general category of "web developer does something they have no idea has a specific (side-)effect" |
| 00:12 | <MikeSmith> | yeah |
| 00:12 | <tantek> | because they don't see the (side-)effect in a browser |
| 00:12 | <tantek> | that's the commonality IMO |
| 00:12 | <MikeSmith> | that is the case with <section> and <article> |
| 00:12 | <tantek> | totally |
| 00:13 | <tantek> | I forgot when, but at some point I gave up on those and the weird philosophical debates as to when to use section article div |
| 00:13 | <tantek> | seemed like it was just wasting authors's time |
| 00:13 | <MikeSmith> | we bought into the complexity and side effects when we added <section> and <article> |
| 00:13 | <tantek> | now I'm like, yeah, just div, and class it for your specific semantics |
| 00:13 | <tantek> | agreed |
| 00:13 | <tantek> | I no longer believe in either |
| 00:14 | <tantek> | similarly - browsers don't really do anything AFAIK special with section or article |
| 00:14 | <tantek> | so they're similarly a source of confusion / noise |
| 00:14 | <tantek> | and by "browser" there I really mean "something the consumes the markup and does something obviously intersting and useful to enough people to make the web developer care" |
| 00:15 | <tantek> | e.g. a search engine consuming the markup and doing something would count too. or FB |
| 00:15 | <MikeSmith> | browsers expose <section> and <article> to the accessibility tree in a special way |
| 00:15 | <MikeSmith> | that is the problem |
| 00:15 | <tantek> | that's neither obvious, nor interesting and useful to enough people |
| 00:16 | <tantek> | I'm postponing fighting that battle (drop section and article) until we have a few more years of web noise / misuse of them that help the stats demonstrate just how useless (or similar to just "div") they are |
| 00:17 | <tantek> | until then I'm advising authors to just use div and pretend section and article don't exist |
| 00:17 | <tantek> | I forget who it was that convinced me similarly of hgroup not being useful (enough) or obvious enough to be worth keeping, and basically, kept following that reasoning |
| 00:17 | <MikeSmith> | annevk: about https://github.com/w3c/web-platform-tests/pull/4801#issuecomment-281622673 (Adjust XHR CORS test to allow custom Content-Type) if you want to get that fixed soon it would be best not to wait for me. For the last two weeks I’ve had almost no time for WPT stuff, and this week I’m working through a backlog of other stuff that’s accumulated. |
| 00:18 | <MikeSmith> | <hgroup> exists just because of the outline algorithm, to prevent subheadings from creating new levels in the outline |
| 00:22 | <annevk> | MikeSmith: okay, good to know |
| 00:22 | <annevk> | MikeSmith: I really want to do work on more WPT stuff personally, but I'm rather dismayed with the amount of reviews I'm getting |
| 00:22 | <tantek> | MikeSmith, right. problem is that "need" ("to prevent ...") does not align in any way with the incentives (or even attention!) of the person who adds or doesn't add hgroup (web author) |
| 00:22 | <annevk> | MikeSmith: it doesn't feel super productive |
| 00:23 | <tantek> | I need to figure a way of documenting that as a feature design anti-pattern |
| 00:23 | <tantek> | when the need for the use (or non-use) of a feature does not align with the incentives of the person expected to use (or not use) the feature, the feature is likely to fail with adoption, or produce noise at best |
| 00:35 | <annevk> | tantek: I think you're misinformed |
| 00:36 | <tantek> | annevk, could be, there are many things |
| 00:36 | <annevk> | tantek: the only problem here is that browsers don't implement the mapping to AT, but implement all other the useful bits |
| 00:36 | <tantek> | I didn't realize there were any actual useful bits |
| 00:36 | <annevk> | tantek: if they implemented the mapping to AT, the feature would work fine |
| 00:36 | <annevk> | tantek: I told you before, styling |
| 00:36 | <annevk> | tantek: standard has other examples, such as not having to care about heading levels |
| 00:37 | <tantek> | I understand those supposed benefits, and have tried to use them over the years, but haven't found them to actually be any easier (less work and more usefully predictable) in practice |
| 00:38 | <tantek> | at this point I expect a lot of <section> / h1..n pollution has occured |
| 00:38 | <tantek> | where author intent != outline algo output |
| 00:38 | <annevk> | tantek: that's just more speculation |
| 00:38 | <tantek> | sure. at some point someone will sample that data and determine some aggregate conclusion as such (as was eventually done with longdesc) |
| 00:39 | <tantek> | I'm willing to wait a few more years as I don't think the result will appreciably change |
| 00:39 | <annevk> | tantek: although you're the first one to bring up that this would not be useful to have, so that's new |
| 00:40 | <tantek> | annevk - I think there has been informal discussion of the near non-existent utility of section / article vs. the cognitive time spent on div vs section vs article |
| 00:40 | <tantek> | that's not new |
| 00:40 | <annevk> | that's very different from heading levels though |
| 00:41 | <annevk> | which is the main practical effect of the outline algorithm |
| 00:41 | <tantek> | sorta. outline algo mixes them all together like spagehtti |
| 00:41 | <annevk> | not really, they're just equivalent from the outline algo perspective |
| 00:41 | <tantek> | hn inside nested divs != hn inside nested sections etc. |
| 00:41 | <annevk> | I can agree that having both <article> and <section> is a bit redundant |
| 00:41 | <tantek> | yes that's a good start |
| 00:42 | <annevk> | Sure, <div> is neutral |
| 00:42 | <tantek> | <article> was a left over from the days when HTML5 was trying to emulate automatic Atom output |
| 00:42 | <tantek> | (and poorly at that) |
| 00:49 | <tantek> | I'd be ok with dropping just <article> for now. That alone would help reduce the discussion / confusion |
| 00:50 | <tantek> | also it may lend more critical mass / usage to <section> (optimistically speaking) to give it a better chance of proving its case to web authors |
| 00:51 | <tantek> | where dropping <article> == redefine <article> to be a parse-time synonym for <section> for backcompat reasons |
| 00:51 | <annevk> | That just shows you're talking about a very different thing than most people have been for the past couple weeks |
| 00:51 | <tantek> | and drop any article-specific attributes etc. (like there were some legacy date things that I don't remember if they were kept or not) |
| 00:52 | <tantek> | past couple weeks? |
| 00:52 | <tantek> | I'm talking in the context of years |
| 00:52 | <annevk> | Yeah, there's been some recent activity on header levels |
| 00:52 | <annevk> | I left a comment at https://www.w3.org/blog/2017/02/on-eme-in-html5/#comment-94776 |
| 00:53 | tantek | is bothered by UTC-presuming datestamps |
| 00:55 | tantek | tries to avoid getting into drawn-out DRM discussions |
| 00:56 | <tantek> | FWIW I tried to get EME/DRM/CDM plugins to work on a recent United flight and it didn't work in any browser (despite the United in-flight wifi / portal being clearly engineered to try to work with EME). So as far as I can tell, the current state is that viewing such "protected" content is just more broken and people will give up. Not sure if that was anyone's intent or who that helps. |
| 00:57 | <tantek> | (failed in latest FF, Safarei, Chrome) |
| 00:57 | <tantek> | and with that data point, I'll leave that discussion |
| 03:37 | <Domenic> | MikeSmith: ah very cool, I'm glad :). I hope that'll help inform any future discussions, in whichever direction things go... |
| 04:17 | <MikeSmith> | Domenic: yeah thanks for having called me out on that. I shouldn’t have cavalierly broken it that way. One problem is I chose before to use the same code to generate both the outline-algorithm view and the heading outline and it wasn’t pretty code to begin with and it justs gets uglier each time I touch it |
| 04:57 | <botie> | kochi, at 2017-02-27 04:03 UTC, MikeSmith said: or somebody for help with that if you need it |
| 05:00 | <MikeSmith> | kochi: ignore that, botie was trying to be overly helpful |
| 07:43 | <kochi> | botie: thanks for your help. yoichio could get the PR merged, and he's gonna apply for Web Platform WG. |
| 07:43 | <botie> | de nada kochi |
| 07:46 | <kochi> | gracias |
| 08:02 | <XhmikosR> | has anyone tried to run the following in the html repo? |
| 08:02 | <XhmikosR> | git reflog expire --all --expire=now |
| 08:02 | <XhmikosR> | git repack -a -d --depth=250 --window=250 |
| 08:02 | <XhmikosR> | git gc --aggressive --prune=now |
| 08:02 | <XhmikosR> | I get all my RAM maxed out when I run this |
| 08:03 | <XhmikosR> | I was trying to find why on earth the repo is so huge |
| 08:08 | <MikeSmith> | XhmikosR: have never tried it but not surprised |
| 08:09 | <XhmikosR> | MikeSmith: has anyone pushed binaries in the past? I can't explain otherwise how the repo got so big |
| 08:10 | <MikeSmith> | the amount of time it takes to just clone the repo is one clue that it’s exceptional |
| 08:10 | <XhmikosR> | yup that is why I tried to run those |
| 08:10 | <MikeSmith> | XhmikosR: well we have some reasonable-sized image binaries in there |
| 08:10 | <XhmikosR> | although in theory GitHub must clean up the repo frequently |
| 08:10 | <MikeSmith> | but I don’t think the images are the problem |
| 08:11 | <MikeSmith> | I suspect the problem is that there have been several times when essentially the entire spec was reformatted |
| 08:11 | <MikeSmith> | nearly every line |
| 08:11 | <XhmikosR> | the images are one potential cause because they are binaries |
| 08:11 | <MikeSmith> | well the spec itself is 8MB+ at this point |
| 08:12 | <MikeSmith> | or maybe 9MB |
| 08:12 | <MikeSmith> | dunno but it was at least 8MB last time I checked |
| 08:12 | <XhmikosR> | it's around 6MB here |
| 08:12 | <XhmikosR> | still that is text |
| 08:12 | <MikeSmith> | OK I guess I am thinking of the rendered spec size |
| 08:12 | <MikeSmith> | anyway it it one file |
| 08:13 | <MikeSmith> | and it is whatever hundreds of thousands of lines |
| 08:13 | <MikeSmith> | and when we have multiple changes where almost all of those hundreds of thousands of lines are touched, I assume that is not something git is designed to optimize for |
| 08:14 | <XhmikosR> | I agree but since it's text it shouldn't cause the issue. Images on the other hand can cause this if they have been changed *a lot* of times |
| 08:14 | <XhmikosR> | oh well :/ |
| 08:14 | <MikeSmith> | incidentally it also makes git blame nearly useless for trying to trace changes for the spec |
| 08:14 | <XhmikosR> | it's just the only repo I get no RAM left that is why I thought I'd ask |
| 08:16 | <MikeSmith> | yeah maybe some time somebody who knows git internals/quirks well can take a look at it and pinpoint what the cause is |
| 08:17 | <MikeSmith> | anyway I’ve never personally been fond of the spec being maintained and one gigantic single file |
| 08:18 | <MikeSmith> | and even less fond of it now for the last year and half or so that we’ve had it in Github and other people need to work with it like that create PRs |
| 08:22 | <MikeSmith> | XhmikosR: about https://github.com/whatwg/html/pull/2230 (Allow <link rel=mask-icon color=… href=…>.), one other thing that Simon had asked about was adding mention that no `color` IDL attribute gets reflected for the `color` content attribute |
| 08:24 | <XhmikosR> | MikeSmith: not sure how to phrase that... |
| 08:24 | <MikeSmith> | OK |
| 08:24 | <XhmikosR> | you guys can push to my fork if you'd like |
| 08:24 | <MikeSmith> | OK |
| 08:25 | <MikeSmith> | will do that then I think |
| 08:25 | <MikeSmith> | if Simon doesn’t first |
| 08:25 | <XhmikosR> | thanks |
| 08:25 | <MikeSmith> | now that I look back at this I see other places we need to touch |
| 08:25 | <XhmikosR> | should we have an issue for the validator too? Also, since I'm not familiar with the tests there aren't any so I'll leave that to someone else too |
| 08:26 | <MikeSmith> | I can take care of the validator without an issue being needed |
| 08:26 | <MikeSmith> | I don’t open a validator issue for every spec change I implement in it |
| 08:26 | <XhmikosR> | all right |
| 08:27 | <MikeSmith> | will try to get all this merged and the checker implementation added soon |
| 08:27 | <XhmikosR> | thanks |
| 08:27 | <MikeSmith> | can do a new release in March for the checker for y’all to use for grunt-html |
| 08:29 | <XhmikosR> | sounds good to me |
| 08:29 | <XhmikosR> | I wish I could contribute in a more substantial way but your whole workflow is new to me |
| 08:36 | <MikeSmith> | XhmikosR: yeah, and it’s a relatively esoteric workflow at that |
| 08:38 | <MikeSmith> | and I guess there’s not much advantage to learning the intricacies unless you know you’re going to be contributing more and will have use of the knowledge for the next thing you want to add/change |
| 11:13 | <smaug> | fetch() doesn't have yet any reasonable way to get partial results/progress events? |
| 11:14 | <annevk> | smaug: streams |
| 11:14 | <smaug> | and streams actually provide that? Like there is ProgressStreams or something? |
| 11:14 | <annevk> | smaug: no high-level abstraction, though we are considering one |
| 11:16 | <smaug> | I guess WebSocket is the best option |
| 11:37 | <smaug> | hrm, service worker spec :/ |
| 21:03 | <TabAtkins> | If a set of strings is closed right now, but I know that in the future it'll be somewhat open-ended (all "valid" strings will be knowable by the browser, but there's a technically infinite number of them), is it best to just spec it as a DOMString, or try to pull of an enum? |
| 21:27 | <wanderview> | I love how when I update to the tip of the spec repo and run `bikeshed spec` I get a bunch of changes to the index.html |
| 21:33 | <TabAtkins> | That implies different bikeshed versions, is all. |
| 21:34 | <wanderview> | TabAtkins: should I include my generated index.html in my PR? |
| 21:34 | <TabAtkins> | Maintainers should have that info in their Contributing.md |
| 21:34 | <TabAtkins> | If they don't, bug them. ^_^ |
| 21:35 | <wanderview> | "To make edits to the design, please send pull requests against the Nightly spec on the master branch. We use bikeshed. So, change docs/index.bs and submit it with the corresponding bikesheded index.html." |
| 21:35 | <wanderview> | I guess that means include it |
| 21:35 | <TabAtkins> | Yes. |
| 21:36 | <TabAtkins> | (Ideal set-up is to set up Travis to build for you and commit that somewhere useful, so there's never any such differences. But not everyone does that...) |
| 23:25 | <TabAtkins> | Man, I am just *loving* the algorithm border to cleanly separate long lists of method/attribute definitions. |
| 23:25 | <TabAtkins> | *So* much easier to read. |
| 23:26 | <Domenic> | Sample? |
| 23:27 | <TabAtkins> | Let me push this and you'll see. |
| 23:28 | <TabAtkins> | https://drafts.css-houdini.org/css-typed-om/#numeric-value |
| 23:28 | <TabAtkins> | Can directly compare it to the methods right below it, which are still using the <dl> pattern. |
| 23:29 | <Domenic> | hmm, i guess i could see it |
| 23:29 | <Domenic> | better than a <dl> yeah |
| 23:29 | <TabAtkins> | Wondering if I want to remove the "when called on a ..." clause and just say `|this|.<dfn>...</dfn> method` |
| 23:30 | <Domenic> | The latter seems weird... what we really need to do is just define "this" in Web IDL |
| 23:30 | <Domenic> | long-standing issue |
| 23:30 | <Domenic> | not too hard, we should just do it |
| 23:30 | <TabAtkins> | Yeah. |
| 23:30 | <TabAtkins> | And then I have to special-case the |this| var to not complain even if it's only a single reference in the algo. ^_^ |
| 23:30 | <TabAtkins> | Well, I can do that right now I guess. |
| 23:30 | <Domenic> | Not even sure it's a var... we've been using <b> in HTML I think |
| 23:31 | <Domenic> | (And <emu-val> in ES specs, heh) |
| 23:31 | <TabAtkins> | It's at the same level of value as the argument objects, which we use <var> to mark up normally. |
| 23:31 | <Domenic> | I dunno, in JS at least it's not a variable in any sense |
| 23:31 | <Domenic> | Just an identifier |
| 23:32 | <TabAtkins> | You're talking major spec-ese nerdery. To normal people it's an auto-bound variable that you get in functions. ^_^ |
| 23:32 | <Domenic> | yeah perhaps |
| 23:33 | <TabAtkins> | It just doesn't seem valuable, especially in these algos, to distinguish it visually from the |value| arg. |
| 23:33 | <TabAtkins> | That said, giving it special linking to WebIDL might make it worthwhile. |
| 23:34 | <TabAtkins> | That is, I'm okay with it having the normal idl-link styling if I can write {{this}} and have it magically work. |
| 23:34 | <TabAtkins> | Dunno what definition type it should even be marked up as, tho. |
| 23:35 | <TabAtkins> | I guess [=this=] works fine too. |
| 23:53 | <TabAtkins> | Hmm, the only way to represent a Map iterator in WebIDL is with sequence<sequence<(keyType or valueType)>>, right? And then manually iterating it to verify that each value is a 2-tuple with the first being of the keyType and the second being of the valueType? |
| 23:54 | <TabAtkins> | (Context is that I'd like to allow a CSSCalcValue to be constructed by passing it either an object of {px:5, ...} or by passing a map, since it's a Map-like already. |
| 23:54 | <Domenic> | I think so, is that what URL does? I bet this was a "wait until two people need it" situation |
| 23:54 | <TabAtkins> | ) |
| 23:55 | <TabAtkins> | Yeah, looks like that's exactly what URL does. |
| 23:56 | <TabAtkins> | I'll file a bug on WebIDL asking for, uh, I guess a map-sequence<> type? |