| 00:31 | <jsbell> | Ah, that's why I haven't seen TabAtkins around recently. :) |
| 00:34 | <TabAtkins> | jsbell: Also: you're in the SF office ^_^ |
| 00:34 | <TabAtkins> | (I'll be there on Tuesday.) |
| 00:35 | <jsbell> | In other news, wrote a content script extension to work around https://github.com/whatwg/meta/issues/10 and now my tabs look ossm |
| 00:39 | <Domenic> | Haha, nice. annevk zcorpan, still holding firm on no PNG favicons for specs? |
| 00:47 | <MikeSmith> | so I just learned yesterday that https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/ exists |
| 00:48 | <MikeSmith> | data showing percentage of use CSS properties and values |
| 00:50 | <MikeSmith> | e.g., https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/--var/ shows CSS variables used in 0.559% of documents, and shows that vast majority of usage is for pixel values and colors |
| 00:50 | <Domenic> | Oh yeah I remember that from when it launched |
| 00:51 | <Domenic> | I wonder how often they update it... July 2017 last update |
| 00:52 | <Domenic> | I wonder what a Bing-powered scan means paired with "Contains data from: Edge, Chrome, Firefox" |
| 00:52 | <MikeSmith> | right, I was confused by that too |
| 00:54 | <MikeSmith> | in other news, one of of the use counters I added to the HTML checker this week was for the style attribute |
| 00:54 | <MikeSmith> | disappointing to find that 65% of documents checked are using it |
| 00:55 | <Domenic> | It's the new hotness |
| 00:55 | <Domenic> | React and inline styles are best friends |
| 00:55 | <MikeSmith> | ah |
| 00:55 | <MikeSmith> | wish they wouldn’t do that |
| 00:56 | <MikeSmith> | but oh well. I guess it means I should have the checker report non-conforming CSS in style-attribute values |
| 00:56 | <MikeSmith> | along with style element |
| 02:28 | <Domenic> | Oooh |
| 07:40 | <MikeSmith> | annevk: log of URLs for documents that have multiple h1 without an section/article/aside/nav ancestor: https://gist.githubusercontent.com/sideshowbarker/8284404/raw/9220fb7b5a1befbabc04dc27943a5255cdfecc3e/h1.log |
| 07:42 | <MikeSmith> | youtube.com is there but when I checked the source I notice the h1s are <template> descendants. The counter/logger should be ignoring those, but I haven’t updated it to do that yet |
| 07:42 | <annevk> | Domenic: I feel like it'd just remove all incentive to ever fix it |
| 07:43 | <MikeSmith> | and current stats out of 40703 |
| 07:43 | <MikeSmith> | ...documents checked: |
| 07:43 | <MikeSmith> | <h1> multiple found 4093 0.100558 |
| 07:43 | <MikeSmith> | <h1> multiple with <section> ancestor found 1024 0.025158 |
| 07:43 | <MikeSmith> | <h1> multiple with <article> ancestor found 903 0.022185 |
| 07:43 | <MikeSmith> | <h1> multiple with <aside> ancestor found 121 0.002973 |
| 07:43 | <MikeSmith> | <h1> multiple with <nav> ancestor found 195 0.004791 |
| 07:44 | <MikeSmith> | https://validator.w3.org/nu/stats.html |
| 07:45 | <MikeSmith> | = 10% of docs have multiple h1s but only ~2% have multiple h1s with section or article ancestors |
| 07:46 | <MikeSmith> | looking at the documents in the logs, you’ll see there are just a lot of lot of them that instead of <section> just use nested <div>s with h1 at arbitrary levels |
| 07:48 | <annevk> | MikeSmith: okay, so those documents are perhaps bad either way, unless hidden is used I guess |
| 07:49 | <MikeSmith> | yeah I didn’t check to see if they were hidden or not |
| 07:49 | <MikeSmith> | but from looking through the documents in those logs, I think in most cases they are not |
| 07:50 | <MikeSmith> | oh you will find some facebook URLs in that log |
| 07:50 | <MikeSmith> | oh not in that one, but I did see it get logged in another instance |
| 07:50 | <MikeSmith> | https://www.facebook.com/events/222607394963984/ |
| 07:53 | <annevk> | "seo_h1_tag" |
| 09:08 | <annevk> | MikeSmith: thanks a lot for these btw |
| 09:08 | <annevk> | MikeSmith: you planning on posting in the issue too? |
| 09:32 | <MikeSmith> | annevk: yeah I will |
| 15:45 | <annevk> | Domenic: I particularly like that is="" becomes syntax and less an enshrined part of the model, but I have a hard time articulating why to myself |
| 16:03 | <Domenic> | annevk: it's always been a bit dubious as an attribute since dynamic changes to it are not respected. HTML has several of those already, e.g. nonce="" and manifest="", but yeah |
| 16:27 | <Domenic> | Does anyone remember that page that was like the same code but was HTML and an image and some other thing at the same time? |
| 16:28 | <annevk> | Domenic: http://lcamtuf.coredump.cx/squirrel/ |
| 16:29 | <Domenic> | nice |
| 16:29 | <annevk> | I wonder if that person now refuses to go HTTPS because of the favicon joke |
| 16:30 | <smaug____> | annevk: you might recall. https://fullscreen.spec.whatwg.org/#fullscreen-element-ready-check doesn't have check for ancestors |
| 16:30 | <smaug____> | but looks like in Gecko we check that if some element is already in fullscreen, the new one needs to be descendant of that |
| 16:30 | <smaug____> | IIRC that was in the spec at some point |
| 16:32 | <smaug____> | I wonder why the spec was changed |
| 16:38 | <Domenic> | "soon to include essential squirrel facts" I wonder how long it's said that |
| 17:22 | <annevk> | smaug____: xidorn has been involved in most changes |
| 17:23 | <annevk> | smaug____: I can git log grep later I suppose, busy atm |
| 17:23 | <smaug____> | sure. It is just probably too late for him atm |
| 17:57 | <annevk> | smaug____: https://github.com/whatwg/fullscreen/issues/45 has a bunch of related links |
| 17:57 | <annevk> | smaug____: basically a lot of it got redesigned |
| 17:57 | <smaug____> | I see |
| 17:57 | <smaug____> | I wonder why |
| 17:57 | <smaug____> | I'll read |
| 17:58 | <smaug____> | thanks |
| 22:04 | <xidorn> | smaug____: there was no point to keep that restriction at that point |
| 22:04 | <smaug____> | aha |
| 22:04 | <smaug____> | xidorn: Gecko just have that still |
| 22:05 | <smaug____> | I kept it while adding support for shadow dom |
| 22:05 | <xidorn> | smaug____: we are quite behind at the moment |
| 22:05 | <smaug____> | yup, noticed |
| 22:05 | <xidorn> | smaug____: though others are more behind :) |
| 22:05 | <smaug____> | aha |
| 22:06 | <xidorn> | smaug____: but because of the way we want to dispatch the event, we may have to reintroduce that restriction |
| 22:06 | <smaug____> | hmm |
| 22:07 | <xidorn> | smaug____: what's the problem with that restriction? |
| 22:07 | <smaug____> | xidorn: I guess no problem. I was just wondering what to do with it |
| 22:07 | <smaug____> | and decided to keep it |
| 22:07 | <smaug____> | I was looking at the spec and didn't see the restriction there |
| 22:08 | <xidorn> | smaug____: ok, we should be adding it back at some point |
| 22:08 | <smaug____> | so, just the generic I-know-I-am-writing-code-against-the-spec worry |
| 22:08 | <xidorn> | smaug____: sorry for the confusion |
| 22:08 | <smaug____> | np, specs change |
| 22:09 | <xidorn> | smaug____: I involved most changes but didn't get much time to follow up in our impl :/ |
| 22:12 | <smaug____> | xidorn: one could of course ask why the spec was changed |
| 22:12 | <smaug____> | since that made at least some implementations behave against the spec |
| 22:13 | <smaug____> | and increasing the risk that implementations do different things |
| 22:13 | <smaug____> | but oh well |
| 22:13 | <smaug____> | nothing special here |
| 22:13 | <xidorn> | smaug____: that actually make all impls behave against... |
| 22:14 | <smaug____> | right, but then some implementation might start to follow the spec and pages relying on that behavior... |
| 22:14 | <smaug____> | and other impls would show up as broken |
| 22:14 | <xidorn> | smaug____: I'm not sure how to balance the risk with the ideal design forward |
| 22:15 | <smaug____> | it is hard |
| 22:19 | <xidorn> | smaug____: anyway, that restriction is expected to back, and the current spec is kind of a middle point between gecko's impl and webkit/blink's impl |
| 22:19 | <xidorn> | smaug____: (with some part ahead of both) |
| 22:20 | <xidorn> | smaug____: and foolip is trying to make blink's impl mostly on par with gecko's so we can try shipping unprefixed api coordinately |
| 22:21 | <xidorn> | there are some changes I need to do on gecko though... |
| 22:22 | <smaug____> | ok |
| 22:22 | <xidorn> | (actually this makes me miss the w3c level way for defining features) |
| 22:23 | <xidorn> | (it would be good to move the part we are not going to implement soonish into the next level, but we don't have such a place to put it) |