WHATWG
2023-01-03
plaintext logs
prev next
source on github
01:58
<Domenic>
annevk: I was thinking of doing it as a holiday project... and I still have 8 days of holiday in Japan. So, probably?
01:59
<Domenic>
"doing it" = "adding full validation error support to jsdom/whatwg-url"
02:00
<Domenic>
Which could then be extended pretty easily with named variants
08:27
<Noam Rosenthal>
annevk: with getting the "internal response" - do I need to do something like "if this is a filtered response, getting response's internal response, otherwise response"
08:31
<Noam Rosenthal>
ok answered on the issue, thanks :)
08:35
<annevk>
Noam Rosenthal: if you find a place where that would be useful we should upstream HTML's unsafe response (perhaps if it's really useful for HTML we should do that anyway, but I still need to convince myself)
08:36
<Noam Rosenthal>
annevk: gotcha, will take a look
08:55
<annevk>
smaug: emilio: did you see my ping in https://github.com/whatwg/fullscreen/issues/149? If you all are still on break feel free to ignore, I'll try to remember to ping again
10:17
<emilio>
annevk: Yeah I think while retargetting would make some amount of sense, it's not really useful for fullscreen/pip
10:18
<frank-dspeed>
what was the exact usecase of shadow dom?
10:18
<frank-dspeed>
css encapsulating, offering slots?
10:18
<frank-dspeed>
what was the main driver does any one know that?
10:21
<frank-dspeed>
i mean i never used it for any usefull use case only for demos when i import css as ESModule so a CSSDeclaration Object and Object.assign(el.style, cssDeclaration)
10:21
<frank-dspeed>
i get cached compose able css that is applyed directly on the element
10:22
<frank-dspeed>
much less to write no id tag clashing nothing i do not even use ID or class when i programatical create html Elements a combo of document.create object.assign gives me total declarativ js syntax to compose elements and styles
10:23
<frank-dspeed>
i write whole app dependent component frameworks in less then 20 lines of code and complex elements with a lot of events like whole IDE Environments in 50 sloc
10:26
<frank-dspeed>
const createComponent = (el = {}, componentDefinition = {}) => {
    Object.assign(el.style, componentDefinition.style);
    Object.keys(componentDefinition).filter((key) => key !== 'style')
        .forEach((key) => (el[key] = componentDefinition[key]));
    return el;
};
const appendNewComponent = (el,tagName, componentDefinition) => el.appendChild(
    createComponent(createElement(tagName),componentDefinition));

// End framework
    const controls = el.appendChild(document.createElement('ul'));          
    appendNewComponent(controls, 'button', { innerText: `${getChildIndex(el)}|+`, onclick: (ev) => {
        el.parentElement.appendChild(new Notebook());
    }, style: { color: "red" } }); 

 appendNewComponent(controls, 'input', { onclick: (ev) => {}, placeholder: `https://.....js`, value: ``, style: { color: "red" } });
    appendNewComponent(controls, 'button', { onclick: (ev) => {}, innerText: `FETCH`, style: { color: "red" } });
11:25
<smaug>
annevk: emilio yeah, I'm not sure retargeting the css state would be useful here.
12:27
<annevk>
smaug: emilio: could either of you elaborate in the issue as to why? Ryosuke seemed to think it was necessary still; I was hoping to avoid having to dive into it myself (I forgot the design rationale)
12:34
<emilio>
annevk: I guess the idea is that it'd be necessary to avoid exposing the existence of the shadow tree (so that you can't know if the element has a closed shadow tree if document.fullscreenElement && !document.fullscreenElement.matches(":fullscreen"))
12:34
<emilio>
annevk: which is true, but it doesn't make much sense to style an ancestor of the fullscreen element based on it having a shadow descendant in fullscreen
12:37
<annevk>
emilio: maybe we should offer :fullscreen-within or something similar to the :focus-within thingie?
12:47
<annevk>
Oh, :focus-within is different. It would be more akin to how :fullscreen is defined per specification.
12:48
<emilio>
Right, that doesn't quite make much sense to me
12:49
<annevk>
Oh, so :focus should match the shadow host, but :focus-visible does not. How many focus-related pseudo-classes do we need?
12:50
<emilio>
Yeah, that focus retargetting is also slightly weird fwiw
12:50
<emilio>
but it's less problematic because what you really want to style is :focus-visible 99% of the time
12:52
<annevk>
I'm also confused as to how it helps as that still gives you a shadow host detector
13:00
<annevk>
Anyway, thanks emilio for the useful example. I'll chat a bit more with rniwa and ntim.
13:01
<emilio>
annevk: focus-visible kind of can match and not mach depending on various things, but yeah it does if you do host.focus({ focusVisible: true }) and then :focus-visible doesn't match on the host but on a nested kid (because of delegatesFocus)
21:44
<jugglinmike>
jugglinmike: I suppose, but that would be confusing for all callers as it's to be used from web platform specs, which don't really use completion records
As a reader familiar with ECMA262, I'm confused by the subversion of that convention. I hear what you're saying about the web platform not using completion records, and that makes me think that maybe the ? shorthand isn't really appropriate. It's only used three times in Infra, so perhaps we could replace it with a different macro-like expansion--one which doesn't rely on 262's control flow conventions. What do you think? (Also, happy new year!)