| 00:03 | <tantek> | MikeSmith - standard rel=icon (still AFAIK) doesn't work in *mobile* Safari |
| 00:03 | <tantek> | if you have support / citation otherwise, would appreciate seeing it! |
| 00:03 | <MikeSmith> | wow |
| 00:03 | <tantek> | yeah it's an annoying wart |
| 00:04 | <MikeSmith> | yeah nuts |
| 00:04 | <MikeSmith> | wonder what reason they could possibly have for not adding support for standard rel=icon |
| 00:07 | <tantek> | MikeSmith: I can't think of any good reasons so I'm not going to speculate on malice / laziness. |
| 08:47 | <zcorpan> | annevk: https://github.com/whatwg/html/pull/2195 |
| 08:49 | <annevk> | zcorpan: maybe foolip can review? |
| 08:50 | <annevk> | zcorpan: I'm technically not working the remainder of the week and only a bit next week |
| 08:50 | <zcorpan> | ok, sure. have a nice christmas annevk :-) |
| 08:52 | <annevk> | You too! 🎄 |
| 09:44 | <smaug> | jgraham: async_test(function(t) { runs the function synchronously, right? |
| 09:45 | <zcorpan> | smaug: yes |
| 09:46 | <zcorpan> | is there a reason we don't have data-dfn-type="element" for only 14 elements in HTML, and not all of them? |
| 09:46 | <zcorpan> | s/don't/ |
| 10:15 | <smaug> | huh, resource selection algorithm is super hard to read |
| 10:15 | <smaug> | cancelling outer algorithms somewhere down deep in inner ones |
| 10:16 | <smaug> | and some wpt tests for it are racy |
| 10:19 | <zcorpan> | smaug: which tests? |
| 10:20 | <smaug> | resource-selection-pointer-remove-source.html |
| 10:20 | <smaug> | at least |
| 10:28 | <zcorpan> | smaug: the resource selection algorithm's synchronous section should run before the <script> executes, IIRC. So x1 should always get an error event. But x2 seems like it is racy, since the sync section ends for the first <source> and then it awaits a stable state again |
| 10:28 | <smaug> | exactly |
| 10:28 | <smaug> | one doesn't know whether event loop spins after </video> |
| 10:36 | <zcorpan> | filed https://github.com/w3c/web-platform-tests/issues/4376 |
| 10:37 | <zcorpan> | in other news https://nerdydata.com/search looks pretty cool |
| 12:01 | <MikeSmith> | zcorpan: I copied the microsyntax descriptions to https://github.com/validator/validator/wiki/Microsyntax-descriptions and marked https://wiki.whatwg.org/wiki/MicrosyntaxDescriptions as obsolete |
| 12:02 | <MikeSmith> | and I changed the checker to parse and use https://github.com/validator/validator/wiki/Microsyntax-descriptions from now on |
| 12:02 | <zcorpan> | MikeSmith: ok |
| 12:04 | <zcorpan> | MikeSmith: looks like it needs some cleanup markup-wise |
| 12:05 | <zcorpan> | yay wiki markup |
| 12:13 | <smaug> | zcorpan: do you happen to know about media attribute in <source> |
| 12:14 | <smaug> | in case of <video> being the parent element, WhatWG HTML and W3C HTML5 spec handle this case differently |
| 12:16 | <smaug> | or foolip |
| 12:17 | <smaug> | resource-selection-source-media.html seems to be related here |
| 12:23 | <smaug> | which is racy test, btw |
| 12:24 | <zcorpan> | smaug: we removed it from the spec |
| 12:24 | <smaug> | zcorpan: ok. apparently no implementation bugs were filed about it |
| 12:24 | <smaug> | at least Gecko |
| 12:25 | smaug | is just helping someone to go through failing media handling related tests |
| 12:27 | <zcorpan> | smaug: this was a while ago, but i can file a bug for gecko |
| 12:27 | <smaug> | zcorpan: I think it is being filed |
| 12:27 | <zcorpan> | ah ok |
| 12:27 | <smaug> | zcorpan: rather annoying just to have this W3C HTML spec :) |
| 12:28 | <smaug> | which some people may accidentally even read |
| 12:30 | <zcorpan> | smaug: you can edit https://wiki.whatwg.org/wiki/W3C with concrete instances of it being annoying or wasting time |
| 12:30 | <MikeSmith> | zcorpan: what kind of cleanup where? |
| 12:31 | <zcorpan> | MikeSmith: < should be < |
| 12:31 | <zcorpan> | MikeSmith: <nowiki> |
| 12:31 | <MikeSmith> | ah OK |
| 12:31 | <MikeSmith> | will fix those |
| 12:31 | <MikeSmith> | I used pandoc to convert it. It’s very good but I guess it misses those |
| 12:33 | <zcorpan> | smaug: bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=19619 |
| 12:34 | <smaug> | thanks |
| 12:35 | <smaug> | odd stuff there |
| 12:35 | <smaug> | why it was removed |
| 12:35 | <smaug> | oh well |
| 13:55 | <inoas> | zcorpan what is the most likely implementation of css encapsulation so that you can stop leakings of part of the html to the body, and from the body to parts of the html? |
| 13:56 | <inoas> | my 2 cents: imho, only this and wide http2 push adoption and the platform will get a huge boost in terms of reliabiltiy/maintainability and speed |
| 13:57 | <zcorpan> | inoas: i'm not sure i understand the question |
| 13:57 | <inoas> | zcorpan currently you cannot isolate CSS to be only applied to parts of the DOM easily |
| 13:57 | <inoas> | and you cannot stop CSS that applies to the whole DOM from being applied to parts of the DOM easily |
| 13:58 | <inoas> | technologies like this try to workaround the issue: http://getbem.com/introduction/ |
| 13:59 | <inoas> | but it creates a mess of classes and takes discipline |
| 14:02 | <inoas> | zcorpan: is my question clear now? |
| 14:03 | <zcorpan> | inoas: so basically scoped styles? plus resetting styles to UA defaults? |
| 14:03 | <inoas> | it should be obligatory that it does not leak outside and optional if you want to leak inside (e.g. not reset UA defaults) |
| 14:04 | <inoas> | it doesn't have to be the declarative shadow-dom or the scoped style tag |
| 14:04 | <inoas> | I am not religious here, but I am looking and hoping for a change that makes the BEM workaround (see above) obsolete |
| 14:05 | <inoas> | If you add HTTP2 server push into the mix, you can create awesome componentized sites |
| 14:05 | <inoas> | very clean separation of concerns, caching on HTTP tech, still only one request |
| 14:07 | <zcorpan> | inoas: i guess i would recommend compiling a list of use cases and requirements, with links to examples that would benefit or are working around the lack of this (like BEM), and list pros/cons of declarative shadow dom or other possible solutions |
| 14:07 | <zcorpan> | inoas: i have no idea what the most likely implementation is though :-) |
| 14:08 | <inoas> | I really don't want to annoy - I just see there are huge gains for the average developers |
| 14:08 | <inoas> | e.g. a lot more speedy sites |
| 14:09 | <zcorpan> | i don't think anybody would be annoyed |
| 14:09 | <inoas> | I don't know much about shadow-dom, the sexy part about a declarate interface to setting a shadow-dom root would be that those who embrace shadow-dom based web components would also get all the benefits because it is a unified solution |
| 14:10 | <inoas> | I read that the mode refers to the javascript of the component being able to read the parent dom, is that correct? |
| 14:10 | <inoas> | e.g. the javascript "leaks outside" |
| 14:10 | <inoas> | is the general dom able to read/write into the sub-tree of shadow-dom? |
| 14:10 | <inoas> | if latter is true, it would be able to "leak inside" |
| 14:11 | <inoas> | and for css the questions are the same and probabily the answers |
| 14:11 | <zcorpan> | i'm not a shadow dom expert, but there is an "open" and a "closed" mode that affects encapsulation |
| 14:11 | <inoas> | so cssMode would be required, which if set to open would inherit the outer CSS, else UA defaults |
| 14:12 | <inoas> | it could even use the same mode attribute, then you are forced however to either open js and css, or none. |
| 14:13 | <inoas> | if I want to open an issue any hints about what to name it and where to open? is github css wg ok? |
| 14:14 | <inoas> | https://github.com/w3c/csswg-drafts/issues |
| 14:15 | <inoas> | annevk: recently said there is little will to add anything to the html parser ... and that's where the whole endavour already ends... I really hope the core teams at whatwg and w3c can see the benefit (or have a lot better idea!) |
| 14:17 | <zcorpan> | inoas: csswg seems ok |
| 17:21 | <ajeffrey_> | annevk: Domenic: another spec question about document discarding... |
| 17:22 | <ajeffrey_> | in https://html.spec.whatwg.org/multipage/browsers.html#joint-session-history it says "Entries in the joint session history are ordered chronologically by the time they were added to their respective session histories." |
| 17:22 | <ajeffrey_> | If an inactive document is discarded, then we traverse to it, which timestamp should we use? |
| 17:23 | <ajeffrey_> | I'm guessing we should use time timestamp of when the document was originally loaded, |
| 17:23 | <ajeffrey_> | otherwise we're going to get into an odd state where the session history order and timestamp order disagree with each other. |
| 17:33 | <Domenic> | ajeffrey_: right, discarding doesn't reset "the time they were added to their respective session histories" |
| 17:34 | <ajeffrey_> | Domenic: and neither does reloading? |
| 17:36 | <Domenic> | ajeffrey_: IIRC reloading does do a navigation with replacement enabled which does replace the history entry with a new one |
| 17:37 | <ajeffrey_> | Domenic: er, that sounds problematic. |
| 17:37 | <Domenic> | Why? |
| 17:37 | <Domenic> | I see |
| 17:37 | <ajeffrey_> | do we not end up with a situation where the timestamp order disagrees with session history order? |
| 17:38 | <Domenic> | My guess is that the chronological order is wrong |
| 17:38 | <Domenic> | As the ordering is well-specified elsewhere |
| 17:38 | <ajeffrey_> | (this is possibly an issue for reloading in general, not just as a result of discarding) |
| 17:39 | <Domenic> | Or maybe "added" is meant to exclude the "replaced" case |
| 17:39 | <ajeffrey_> | Domenic: where else is the joint session history order specified? |
| 17:39 | <Domenic> | ajeffrey_: things are added to it one by one. You add things at the end |
| 17:40 | <ajeffrey_> | The session history order is fine, it's the joint session history that is chronologically ordered. |
| 17:40 | <Domenic> | Oh... /facepalm |
| 17:40 | <ajeffrey_> | Domenic: :) |
| 17:40 | <Domenic> | OK then my thing about reloading is probably wrong |
| 17:40 | <Domenic> | But hmm |
| 17:40 | <ajeffrey_> | I think the idea is that reloading shouldn't update the timestamp. |
| 17:41 | <Domenic> | Yeah that seems likely |
| 17:41 | <Domenic> | In general replacement should not update the timestamp I am pretty sure |
| 17:41 | <Domenic> | Wouldn't it be great if we added an explicit concept of timestamp to the spec?? |
| 17:42 | <ajeffrey_> | Domenic: yes, there is an implicit timestamp in the jsh, it's just not explicitly discussed. |
| 17:42 | <ajeffrey_> | Domenic: should I file an issue? |
| 17:42 | <Domenic> | ajeffrey_: I think it's all part of the "update session history to match browsers" issue |
| 17:42 | <Domenic> | Maybe add a comment there |
| 17:43 | <ajeffrey_> | Domenic: do you know the issue number? |
| 17:43 | <Domenic> | I can search for it |
| 17:44 | <Domenic> | https://github.com/whatwg/html/issues/1454 |
| 17:44 | <ajeffrey_> | Domenic: thanks! |
| 17:49 | <ajeffrey_> | added comment https://github.com/whatwg/html/issues/1454#issuecomment-268592522. |
| 17:52 | <TabAtkins> | https://github.com/w3c/csswg-drafts/issues/711#issuecomment-265861196 |
| 18:36 | <tobie> | Domenic: your comments on https://github.com/heycam/webidl/issues/188#issuecomment-268601139 appreciated |
| 18:37 | <Domenic> | tobie: they all seem like good questions. I was kind of hoping we could just get away with telling everyone to define their own toJSON(), but maybe that's not convenient enough. |
| 18:37 | <Domenic> | The mixin idea is intriguing |
| 18:38 | <Domenic> | I wonder what bzbarsky thinks of it |
| 18:39 | <tobie> | Domenic: there's an added issue with toJSON, though: the return value of serializing operations is currently defined with a mix of IDL types and what are de facto infra types. |
| 18:39 | <Domenic> | yeah |
| 18:39 | <Domenic> | I guess asking spec authors to create their own dictionaries or similar is annoying |
| 18:40 | <Domenic> | well but they only need to do that if they need something custom |
| 18:40 | <Domenic> | so if you need a custom version: define a dictionary type; define a custom toJSON() that returns an instance of that |
| 18:40 | <tobie> | Domenic: well, we could get away with using record<DOMString, any> or the like I guess |
| 18:40 | <Domenic> | (or returns a string or other JSON type) |
| 18:40 | <Domenic> | Hmm true |
| 18:40 | <Domenic> | But the shape is fixed generally so dictionary is better |
| 18:40 | <Domenic> | The question is how to make it easy for the case where people just want to serialize all attributes |
| 18:41 | <tobie> | that's my suggestion #4 |
| 18:41 | <tobie> | just say: toJSON defaults to that behavior |
| 18:41 | <Domenic> | Yeah |
| 18:41 | <Domenic> | I guess I would probably want something explicit, like = default |
| 18:42 | <Domenic> | because otherwise people will go searching for the definition in prose and not find it |
| 18:42 | <tobie> | well, you could just have an abstract operation in WebIDL and refer to it in prose |
| 18:43 | <Domenic> | Yeah I guess so |
| 18:44 | <tobie> | It feels like you either want to use an abstract serialization mechanism throughout or only use toJSON. |
| 18:45 | <tobie> | Mixing the two creates a lot of questions when they collide in the inheritance tree. |
| 18:47 | <tobie> | Domenic: anyway, thanks for your feedback. I'll wait for bz's comments and move on from there. |
| 18:48 | <Domenic> | Yeah. I think you are on the right track. Custom toJSON, either completely custom or delegating to some helper abstract op in Web IDL. |
| 20:44 | <tobie> | Domenic: wrt to https://github.com/heycam/webidl/issues/255, what are your thoughts? |
| 20:45 | <secureSuggest> | Hello. Is here an expert for html5 input elements? |
| 20:45 | <Domenic> | tobie: https://github.com/heycam/webidl/pull/257#issuecomment-267100851 |
| 20:46 | <secureSuggest> | I think I have a suggestion for extending the standard, so I'd like to find someone who wants to talk about that topic. |
| 20:48 | <tobie> | Domenic: yeah, saw that. Is your suggestion to fix the language that originally made a distinction between the DFN and IDL type and no longer does? |
| 20:48 | <Domenic> | tobie: yeah I guess so. I don't see what the distinction buys us. |
| 20:49 | <tobie> | Domenic: it's sort of easier to reason about (at least that was my conclusion last week). |
| 20:49 | <Domenic> | Hmm I don't really see how. |
| 20:51 | <tobie> | Domenic: well for one the fact that we're referring to it in plural multiple times throughout the spec was a good sign we were talking about the DOM exceptions and not DOMException |
| 20:51 | <Domenic> | tobie: I thought it just meant we were talking about DOMException instances |
| 20:51 | <Domenic> | I don't know what a "DOM exception" is, except a DOMException instance. |
| 20:52 | <tobie> | Domenic: a DOM Exception is anyone of "XXXError" DOMException. |
| 20:53 | <Domenic> | tobie: that doesn't really help; what are those? Are they DOMExceptions? |
| 20:53 | <tobie> | *a DOM exception... |
| 20:53 | <tobie> | they're an abstract concept, much like simple exceptions. |
| 20:53 | <Domenic> | simple exceptions are not an abstract concept |
| 20:54 | <Domenic> | They're one of four-ish specific types |
| 20:54 | <Domenic> | a TypeError is a simple exception |
| 20:55 | <Domenic> | (5) |
| 20:55 | <Domenic> | I just can't see anything in https://github.com/heycam/webidl/pull/257/files which is improved by the distinction |
| 20:55 | <Domenic> | In general I can't envision a situation where it's helpful to say "no, that's not a DOMException, that's a DOM exception" |
| 20:56 | <tobie> | heh |
| 20:58 | <tobie> | Ok. I'll see if I can fix the non-sensical sentences instead. |
| 20:59 | <tobie> | Then work on adding the ability to set props. |
| 20:59 | <Domenic> | set props? |
| 21:00 | <tobie> | On DOMexceptions |
| 21:00 | <Domenic> | oh, create new exception types you mean? |
| 21:00 | <Domenic> | Or maybe setting own props on normal DOMException types would be fine, interesting |
| 21:01 | <tobie> | Yeah. I think that was the conclusion from TPAC. |
| 21:01 | <Domenic> | Huh OK, I don't remember that at all, but I'm sure that's just my memory :) |
| 21:01 | <Domenic> | It is nice and simple |
| 21:02 | <tobie> | Yeah. It's in the notes. |
| 21:02 | <Domenic> | \o/ |
| 21:02 | <tobie> | You said pretty much the same thing when it was mentioned then. :D |
| 21:03 | <tobie> | I need to think through the slots a bit more. |
| 21:03 | <tobie> | Understand the end goal better. |
| 22:42 | <Domenic> | TabAtkins: I'm confused, is it offset-before (https://drafts.csswg.org/css-position/#logical-box-offsets-beaso) or block-start (https://drafts.csswg.org/css-logical-props/#logical-controls) ? |
| 22:44 | <weinig> | annevk: hey, in https://github.com/whatwg/html/issues/1102, I can’t quite tell, are you advocating merging <input capture> attribute into HTML? |
| 22:47 | <Domenic> | TabAtkins: nevermind, cbeisinger found https://drafts.csswg.org/css-logical-props/#propdef-offset-block-start for me and told me css-position is outdated |
| 22:53 | <annevk> | weinig: yeah, at the very least least cross-reference |
| 22:53 | <weinig> | annevk: ok, cool |
| 22:53 | <annevk> | All your HTML belong to HTML |
| 22:54 | <weinig> | annevk: agreed |
| 23:51 | <rniwa> | Domenic: yt? |
| 23:52 | <Domenic> | rniwa: yep |
| 23:52 | <rniwa> | annevk: yt? |
| 23:52 | <rniwa> | Domenic: so, do you know anything about navigating to a fragment? |
| 23:52 | <rniwa> | Domenic: as far as i read the spec, it seems to imply that it needs to happen in the next task |
| 23:52 | <Domenic> | rniwa: mehhhh i reviewed some patches on that section of the spec at some point. Let's dig in... |
| 23:53 | <rniwa> | Domenic: however, this is what we implement nor do we intend to implement this. |
| 23:53 | <rniwa> | not* what we implement |
| 23:53 | <rniwa> | Domenic: scrolling on iOS happen completely asynchronously |
| 23:54 | <Domenic> | rniwa: tracing through spec links it seems like we end up in https://drafts.csswg.org/cssom-view/#perform-a-scroll |
| 23:55 | <Domenic> | rniwa: it sounds like maybe what we want here is to give UAs license to always do a smooth scroll? |
| 23:56 | <rniwa> | Domenic: or maybe that the definition of "instant scroll" needs to change |
| 23:56 | <Domenic> | rniwa: yeah maybe that would make sense... so if you do document.body.scrollTo(x, y), document.body.scrollTop === x; that will generally be false in WebKit? |