<beverloo> https://docs.google.com/presentation/d/14EFlm3VIDvE7WJnyEZKKQfY3S5wLF9nQM9SPVbqosqA/edit#slide=id.p
PB: update on progress…
... having a single push service intermediary helps reduce battery usage, means the application doesn't need to identify that service and can just trust it.
... there are web services using this.
... End-to-end encryption makes quite a barrier to adding things. This has led to creating push aggregators - people who will collect the information and distribute it.
... not so wide support for advanced notifications. Displaying basic stuff is, but buttons, inlines images, etc, not so much. We are getting there, but the API still could do with more implemented interop.
... Path to Rec. The API itself is pretty old and stable, but a couple of minor ideas for consideration.
... Only allows one subscription per service worker, so if your connection drops between unsubscribe and resubscribe, you lose the connection to the user.
... When you get a message, implementations require you to notify the user. But browsers don't always do that, based on heuristics about whether we think the user trusts that site. So we should be able to tell the developer that the user wasn't getting anything a notification.
... We would like to more this to CR in the next few weeks… so now is a time to comment.
... Open non-blockers
... Push depends on servers and clients, and the clients depend on external input, making it hard to develop a test suite.
... Another issue is notification permission spam. Everyone requests the permission,, and it is annoying.
... Trying to work out how we can reduce that, but ideas are welcome.
LJW: You said you think we are good for CR in the next few weeks? For that we need to have the tests prepared - is that viable?
PB: We have various tests, what is coverable automatically is in WPT, there are also manual tests we have.
LJW: So we just need to add that manual test info to the automated report?
PB: Yes.
... Thank you.
MG: Spec gives metadata about your website to help it be installable. Has names and icons and stuff, defines an event to request being installed, …
... grab bag of stuff related to instyalling and running web content as a desktop app.
<marcosc> https://github.com/w3c/manifest/wiki/TPAC-2018-Agenda
MG: Update on changes, implementation status, ...
... Lots of progress on implementation. Was on Firefox/Chrome for Android last year. Now we have it on various other Chromes, Safari, and Bing is scanning sites and indexing them and you can install them through the windows store. Samsung and Opera have their own implmenetations too.
... the marketingese for sites with manifests is "PWA" - we have seen big uptake in the last year.
... Big famous websites are doing it.
... We've made some breaking changes - some are not implemented. We changed the default scope from that of the page you got the manifest from to a root that is more stable. The algo matches service worker
... when you get out of the dcope, you should have browser UI showing. We had said you cannot navigate outside the manifest, but can open in a new tab. Implementations were following this, but it is a bad idea - breaks the assumption of HTML that top-level context is what gets navigated. So you couldn't do authentication in a 3rd-party and gthen try to get back, because now you're no longer in the app view.
... with separated browser instances, you couldn't do that at all…
CMN: Doesn't that allow for phishing because you have the page in the app look just like you are in a third-party login situation?
MG: Yes. We recommend using non-spoofable UI in addition, which we do in desktop but not on Android. So you haven't got *exactly the same as native UI" but close. We know it's an issue...
... The other change is an optional feature currently unimplemented, called masking icons. Android now makes you put icons in a little white circle. Or you provide a full bleed rectangle and the system crops something out. So on that OS you have to provide a full-bleed icon designed to be cropped in arbitrary ways.
... we added a feature to provide a separate icon that meets this use case.
... saying exactly which pixels might get cropped out. Want to ensure developers still provide an icon that works on most platforms.
... will have to see whether that gets picked up.
... To get to CR we need testing. We have almost nothing beyond basic IDL. This stuff is hard to auto-test, involves different user agent UI across browsers, no API to trigger an autoinstall
... Looks like we will have to do a bunch of manual testing.
... We looked for features at risk yesterday, BeforeInstallPrompt has one implementation. ServiceWorker is meant to let you declaratively register one - don't think it is implemented anywhere.
MC: Idea was that synching two devices would enable you to automatically get a serviceworker, but it didn't get done.
MG: There are some things that are for scrapers not browsers.
... We are expecting to leave stuff for a year and see what happens.
... We rewrote to use WebIDL, but this is a JSON format not a JS API.
MC: There are some feature requests related top making things more like desktop UI
... discussion on back button, because inconsistent UI is odd. Proposed a CSS query to find out, so you don't add a button when there is one already.
MC: Doing test-driven development means we have higher-quality specs, we can verify them, it increases the likelihood of features happening. Would be good to move toward a workmode where testing is a core part of the specs we make. There are different things we can do - have a template where you promise to test stuff, or you can insist on a test before you merge a change…
... I would like the hardline policy, which leads to high-quality specs.
<marcosc> https://github.com/w3c/payment-request/pull/749
MC: having it in the PR template also helps us go back and find out where the tests are easily. (We also flag implementor commitment in Web Payments)
... having a strong signal about implementation in whatever space a spec gets implemented is ery useful.
... Downsides: Sometimes we have a feature and we don't like it and we wasted time on testing. But that effort helps figure out what was wrong.
... There are PRs that are otherwise ready, but are waiting on tests.
... We can fiddle around with the template to figure out what you need for a given spec
TL: +1
CMN: +1
LJW: When you have something with manual and automated tests is there an easy way to handle that?
MC: Yes there is a manual-test-result integration tool in WPT.
... We cannot currently tell wpt.fyi to run stuff behind flags.
MG: We had a discussion with implementors about how to notify breaking changes. That's why we set up a template - we want to have a discussion with all implementors
... it is hard to always get input from implementors.
CMN: It is hard to define all the implemntors, or get their attention. I hope at least the 4 browsers we typically talk to pay attention
AvK: I would not assume that. Reach out over email, IRC, or proactively file bugs and see what happens.
MC: There is no magic technique to do this.
LJW: We have Pubstatus where we try to keep track of the things we are doing, a pile of Github repos, and groups working on each of those things. There is often not much cross-pollenation, we feel fragmented.
... Does anyone have better ideas about how to communicate better?
MC: Instead of large-room meetings, do more standup style updates.
... then go off and split into pieces to work intensely.
we have 4 days and web manifest gets 15 minutes.
scribe: then at the end we get together again and figure out what we achieved.
<mgiuca__> chaals: Yes, but... it's great that for some groups like Web Components, you had a small group. But some people may need to attend lots of these "unconference" meetings.
<mgiuca__> ... How are you going to make sure people can come to all the meetings they need to go to.
LJW: Who would have been torn between manifest, push.
<mgiuca__> chaals: Would need each group to make a F2F agenda, and stick to it.
<mgiuca__> ... So that people can attend the meetings when they are relevant.
TOC: I am the only person from my team in this room, and I prefer the linear model
[back and forth on benefits, mechanics…]
MG: If you work on a tiny spec you then have a risk of not getting any attention. Sometimes small specs should have a pleanary thing instead of a full unconference.
CMN: Yes. Likewise, we need to think about managing conflicts, but I think it would be goo to move in this directions.
LJ: W: We probably want a blend of approaches. SHould we make a strawman?
DM: How do I make sure the people I need to atlk to are available, and not in some other session working on some other important spec.
LJW: What do we do betgween now and next TPAC?
MC: Reduce the number of specs.
... there are specs that haven't moved in 2 years, I think they should go.
TOC: Would be helpful to have a Web components F2F in half a year again.
[+1 to tess]
LJW: Are there others who would be interested in F2F work?
[crickets]
[break]
<marcosc> mk; problem we are trying to write file and create file editors. So make possible to write/save, etc.
<dmurph> Explainer: https://github.com/WICG/writable-files/blob/master/EXPLAINER.md
<marcosc> mj: various attempts have been made at this in the past
<marcosc> scribe: marcosc
mc: who else is interested in implementing this?
<ericwilligers> File handlers: https://github.com/ewilligers/file-handling/blob/master/explainer.md
mj: there are a bunch of different use cases that we try to address?
anne: what's the UX for this?
mj: file picker
anne: that doesn't seem acceptable
mk: we are still trying to work out the UX model
... the hard part is making this obvious for users.
<Zakim> annevk, you wanted to ask about UX
ew: we application should be able to register themselves to handle certain types of files
mj: what we were thinking is that when you try to write a file, you might show a file dialog
anne: so then you get to pick your same location?
mw: we need something for users to do this, but we still to work out the details
mc: we need to get a standards position from Mozilla
to: I don't know how mature the proposal is, so can't really comment
anne: we probably want to see this more fleshed out, e.g., using streams
mw: we have the file system API in Chrome, so it might be worth experimenting in that API.
ja: it would be useful for IDB for writing files
mk: we were not planning to mix the IDB and files
as: we have this something like this in gecko but we wnat to get rid of it
... what's the security model around this?
mj: ...sandboxing...
m?: scoping this down to a single directory doesn't solve security problems.
mj: in MacOS there are permissions specific to where apps can write. We could learn from that.
a?: we have something similar in Windows with regards to permissions to where you can write.
mw: there are 3 separate use cases, one a web. There is a thing on a disk, but you get the representation on the website. And the third is you get a file from another webpage.
mg: this is not exactly web share target. I'd like to explore for the third use case, where a web page can edit a kind of virtual file that could be on disk or on another website.
<mgiuca> https://github.com/chromium/ballista/ our (very old obsolete) plans around web-to-web two-way editing.
mw: the questions of persistence is relevant
tn: I'd like to get more interest from browser vendors. How can we do that?
to: we are interested to have a look when the proposal is more concrete
as: Mozilla wants the file reader to go away
anne: we should try to see which of these use cases we can do today over existing APIs
<annevk> new Response is great
http://github.com/mozilla/standards-positions/
<annevk> I'm not sure that got minuted correctly. What I meant was trying to add APIs for dealing with files without requiring new UX.
mc: what's the process for bringing new work item in?
mw: you should look at the scope of your charter and make sure that something like this would be naturally in scope.
<ericwilligers> https://wicg.github.io/web-share/level-2/
<mkwst> (Assuming, of course, that folks think this is a problem space the group ought to be interested in (which I think it is))
ehttps: //wicg.github.io/web-share/level-2/#usage-examples
https://wicg.github.io/web-share/level-2/#usage-examples
<ericwilligers> https://wicg.github.io/web-share-target/
scribe: ew explains how it works....
ew: we are interested in sharing files. There is an implementation Chrome and there has been some implementation in Safari in Mac and iOS.
mc: there are two APIS - would it be worth combining them.
mg: we got back feedback from Mozilla that having share without share-target would not be acceptable to Mozilla
... the web share target doesn't make sense without web manifest. So it could be that web share target just becomes a thing that's defined as part of web manifest
mc: so there is some interest on from multiple browser vendors
to: sure, tho I don't have any particular feedback on the level 2 stuff.
mg: so I'm looking for interest to see if this should be part of the charter
mw: given the web share is in at least two implementation, it might be appropriate to make sure it's in scope. Graduating web share seems reasonable. But maybe target could use some more incubation.
mg: we plan to ship web share target soon. It's been in Canary for 6 months for the purpose of testing?
mc: have you had feedback from twitter?
ew: they are keen for us to ship it
ty: in Windows, they support a very similar mechanism.
aa: the proposal seems reasonable.
<mkwst> (Ali Alabbas from Microsoft)
mc: we should go back to Mozilla's standards position.
db: we should look at how it overlaps with registerContentHandler()
<mgiuca> https://github.com/WICG/badging
explainer https://github.com/WICG/badging/blob/master/explainer.md
mg: show indicators in icons
... on installed PWAs
to: why doesn't this apply to tabs in general?
mg: slightly different - this is supposed to be application level. So it wouldn't work for a web app that doesn't have multiple tabs open that wants to display things numbers per tab.
to: I think it would be weird if they were different APIs.
mg: just want to point out that they are slightly different.
anne: it could be at the origin level
cross talk
mg: we could make a distinction between OS app level and tab level
<scribe> ...continued explanation of the API in the explainer... simple API with set() and clear(), with string or number
to: what kind of data can you set it to?
mg: trying to restrict it to what platforms support. There is a question around if this should tied to notifications. But we don't want it to be tied to having to call the API over and over to represent the number to be shown.
to: if you are not intended for this to work on Android, why are you planning to work on thiss?
mg: for desktop
to: I would not be interested in different API that would work on both mobile and one on desktop
mg: on Android there is just no way to show a badge. But that's a limitation of that particular OS.
... so it would only be set on platforms where it would be supported.
dd: would this work on iOS?
to: I don't think this is deficiency on Android. For notifications, we looked at the cross section of supported things across platforms.
anne: it would be annoying if for a particular use case, twitter had to send notifications to make this work.
... for iOS, I don't get notifications, but I do get updated badge numbers
mg: yes, this is what iOS does - it sets the badge number
anne: is there OSs that take a string
mg: on MacOS it does support a string
... on windows 10, you can set a specific set of icons for the badge ... I don't want to bake that into the spec, but just for example
anne: there could be potential problems with emojies
<annevk> Please restrict it to secure contexts
to: I really like the use case, but I need to review the design.
... I think it's a good idea in general
... it would nice to do it with no script
... e.g., a declarative push message
pb: there might be race issues with that ... we have looked at that with notifications
mg: the proposal says that the use agent can reset the state
ja: I worry that if you can read it and set it could become racy
mc: one of use will file a Mozilla standards position
<annevk> mgiuca: I also kinda wonder if we shouldn't just stick it on Notification or some such to avoid yet another global
<annevk> mgiuca: or navigator.setBadge
<ada> +present
<dmurph> preset+
ada: WebXR has an interest in Gamepad API
<tink> me If you haven't already, please present+ yourself to be recorded as present.//me If you haven't already, please present+ yourself to be recorded as present.
sa: we've like to get to a 1.0 spec. We'd like to talk about current open issues. And if we have time, do a little demo in Chromium
... presentation ....
issue 22... polling vs events
sa: larger discussion we need to have after v1
... issue 22 is really a v2 issue
Issue 24: changing api to match SDL2.
issue 74: finger printing concerns... we could move that to v2...
dd: all DOM events are already keyed off navigation time. It would be strange to special case this API
... I will make a comment on that issue
Issue 70 - to get user consent before in a async manner before they can access a gamepad
<Domenic> Filed https://github.com/w3c/gamepad/issues/74
r?: async can cause challenges for implementations
sa: besides being hard, it's been working ok
... discussion of issue 74 ...
Issue 71: clarify connected/disconnected event.... need to work on that
Similarly with issue 72
the wording is unclear around "interacted with"
means
Issue 73: standardizing ID fields.... different browsers return different things for the ID field. Other put the other vendor information. It doesn't seem to be a fingerprinting issue... but having clarification around what an ID should represent would be great. Also, possibly not providing an ID field might be good. Which might be valid... but being able to visually represent an image of the controller could can be helpful.
??: In WebXR, we need a way to identify the controller, because people can't seen them in VR. One proposals has been to use a 3d model, but there are a bunch of issues with that
Nell_Waliczek: the issues that we would see, you might not see any controller at all because you could not represent the controller at all... so need some kind of fallback.
mg: in the regular gamepad space, have you considered some kind of "map" where the buttons could be returned by the user agent to the site as images, so they can show the correct buttons for the user's specific device.
as: the evolution of controllers would be a concern
mg: the UA might be in a better position to make that determination of what to show
dh: there should be more coordination across groups around ID, given the requirements of different groups
sa: agree... we should continue to evolve that in v2
Issue 82: getFamePads() returns different things in different UAs
sa: we need to settle on something across UAs
nw: what happens when there is no one is connected? and when someone disconnects a controller and connects a different one?
as: it would be part of the same issue
... we need to really clarify the spec around all this before we can call v1 done
... there are some issues like multitouch surfaces, etc. support for light indicators
DEMO TIME!
issue 27 about multitouch controllers... different inputs, different shapes different sizes
this is not landed upstream
in Chrome
ian kilpatrick: make sure you file a TAG review, because it's part of Chrome's intent to implement process
lw: does it make sense to charter this as a V2 spec?
... as part of immersive web
... or include it Web Apps WG
dm: from the storage side, we hit a lot pain points from async APIs... about getting the gamepads, it can cause jank... things that are asynchrounus are generally better when talking to OS stuff.
ik: is it worth moving to V2?
anne: I don't understand the concern, given that it's already async.
... one issue you didn't address is issue 8... are the arrays live, etc. that's a pretty fundamental issue.
... at what point do these things get updated, etc.
... there are interop issues
mg: I'm not sure what live means here
anne: are the slots underneath the getters updated dynamically or not
as: we will check, we seems to have interop on these things, but will check what's in the spec
anne: so the objects static?
as: yes
<ada> sorry wrong #
:D
<fantasai> scribe: fantasai
<rniwa> https://github.com/w3c/webcomponents/issues/763
rniwa: Here's the agenda
... First item is issue 179, how should varions document internal references work
github: https://github.com/w3c/webcomponents/issues/763#179
rniwa: ...
... It will resolve the full URL
... There's no way for authors to reference elements in the shadow tree
... But there are other internal elements, like labels and stuff, these are done by references in the DOM
... Want to come upw tih some module to make it work
... That we can apply to all other such references
bz: Gecko has some stuff to do this.
... In an ad-hoc way, if we know what the element is where the URI originated
... so this work sofr SVG attributes, as opposed to CSS properties,
... and form attribute on controls
... If we know what elements they originated with, if they go with shadow root
... we can call getElementID on that shadow root
... There are some complications in CSS
... If it's a style sheet you can do getElementID on the document
... but not clear to me what hte situation is
emilio: For stylesheet case, rules from the document don't apply to nodes in the shadow tree
... Might be more complicated with slotted which crosses shadow tree, but in shadow tree there's no rules from the document
... Then there's user style sheets which could apply to the shadow tree
... At least right now, all browsers agree that to resolve the URL based on the tree, the element that matched the rule
... Let's say you have a shadow tree with ::slotted(div) and then filter: url(#foo)
... So The rule applies to an element in the document, even though the rule comes from the shadow tree
... I think as of right now, everybody agrees to look in the document
annevk: Is that because style shet associated with doc?
emilio: Because style sheet assocated with shadow tree
rniwa: CSS has its own special casing of shadow element
bz: Only reason CSS comes up here is because SVG attributes are supposed to behave just like corresponding style properties
... E.g. if you have a rect="..." vs rect: ..., should behave the same
rniwa: Let's say ou have anchor tag that has href
... Does that anchor tag ... another element in the shadow tree
... href in anchor and link elements are to be resolved against base uri
... Making href behave differently in <a> vs <use> would be confusing
... Eithe rway we have an issue that if we made the href another fragment based name reference behave like CSS, then it would be confusing
... in partiuclar in svg, there's xlink href and regular href
... ...
bz: There is nothing really that stops us from sayigng if you have <a href> in shadow DOM that once you done URL resolution happens to be same document referene
... We could define that document elmeen tnode [...]
... If all you're doing is na anchor scroll,..
annevk: That breaks encapsulation, though
rniwa: There's no way to represent an url
bz: <a href> is weird compared to things, because of side effects
annevk: Personally I think special-casing <use> might be OK
... It's similar to filter
... Whereas <a> is about invoking navigation element
... Ones that can invke navigation
?: Can we discuss Tab's proposal
<rniwa> https://github.com/w3c/webcomponents/issues/179#issuecomment-410071854
rniwa: Tab's proposal is thtat fragID should be local to the shadow tree
... And URLs should use CSS rules
annevk: This doesn't go into <a> and <area> elements
rniwa: My position would be that this wouldn't work for anchor element
... Are we doing some specila parsing of the fragment URL? are we doing resolution of space URI ... on this document
annevk: CSS has that construct already, right?
bz: In CSS a URL is either absolute, or is a frag-id URL, based on whether starts with #
... I think that's what Tab is thinking of
... It would make some sense to do that
rniwa: It just doesn't work for some of the hrefs, it doesn't work for anchor and area
bz: I think that's OK
rniwa: So just special-case <use> element
bz: Have those resolve to an absolute URL
... They're not doing a look up o n the document
... They're feeding the URL into a big box that is navigation
rniwa: My take is that it's probably cleanest to do ?
bz: Not specific to <use>. SVG attributes have a ton of attributes that take URLs
rniwa: So you're proposing we use this mechanism for all these atrtributes
bz: Yes, it makes sense that an element in the SVG shadow dom would want to reference a paint server also in that shadow DOM
annevk: The other SVG attributes that take URL all already map to CSS properties, so it makes sense that they have the CSS mechanism
... Whereas the <use> element doesn't have a CSS equivalent
emilio: There's the element() function
rniwa: Do other attributes use URL format?
bz: yes
... e.g. fill="url(...)" or fill: url(...)
...
... In theory the SVG spec says those attribues bhave as the corresponding CSS properties
rniwa: Seems like we should have a concrete list, instea of vaguely saying that an attribute behaving like a CSS property...
<Domenic> All the properties/attributes: https://svgwg.org/svg2-draft/single-page.html#styling-PresentationAttributes
<Zakim> tink, you wanted to figure out the charter thing
<Zakim> fantasai, you wanted to ask why
fantasai: I'm not understanding how the proposal is dfferent from Tab's proposal
rniwa: Proposing to resolve on Tab's proposal for SVG attributes
fantasai: And other things?
rniwa: Not for other things
fantasai: So what are we resolving to do with things that are not SVG attributes?
annevk: href invokes navigation algorithm, which we don't want to mess with
... Navigation is document-wide
rniwa: label is already fixed
ewilligers: ...
rniwa: For those we'll have a specific list
<hayato> [Shadow]: url fragment identifiers should be followed into ShadowDOM: https://github.com/w3c/webcomponents/issues/66
bz: <a> and <link> href, this does not apply
rniwa: So this is issue 3219
tomayac: This is about referencing across shadow DOM
annevk: Let's go back and record resolution to previous issue
RESOLUTION: We would take Tab's proposal in #179 (comment) and have an explicit list of elements and attributes to which this behavior would apply since this would not make sense for things like href in anchor or area element.
tomayac: This is for ability to make label custom element
<xfq> #179 (comment) is: https://github.com/w3c/webcomponents/issues/179#issuecomment-410071854
tomayac: To amke a lable, you need an ID
... And I though this was resolved with similar issue, give reference instead of ID
rniwa: ...
Domenic: There's some requirement from rniwa that this only works in one direction, and wanted to ask if that's OK with tomayac
rniwa: Our requirement is that the node outside the shadow tree cannot reference a node insde the shadow tree, because that would break encapsulation
tomalec: Could the shadow host be referenced? and then forward the reference?
TL: delegates the label
<aboxhall> Could we specify the input-label relationship in the other direction instead?
Domenic: I know tkent's form submission API is related to this
... It seems different that you're delegating to an existing orm element, but not sure
bz: what do you do if you have multiple form elements inside your shadow tree?
Domenic: You can imagine a date input with three parts
... I'd delegates-label="ID" and you can specify which input to delegate to
bz: So shadow root would delegate that information, right?
... i think that makes sense
rniwa: Simple case of label wrapping an element, which happens to be in the shadow tree
... Other case is comple component like date picker, which there are individual labels for each part of the date
Domenic: You have a label for the date, and then three input fields
... And slashes between
... Or you have a time, and then : between
... It's pretty obvious, you don't need labels for each one
chaals: No, you need labels for the pieces of a date, in particular (because i18n)
... There are also people who want to put for time as well
hayato: IIf we failed lookup in local shadow tree, can look up ancestor tree, so if we introduce delegation mechanism, consistent syntax so that can be sued by any other such features
... Tab's feature is proposing such a mechanism
... Consistent syntax
<bkardell_> (same link posted earlier)
rniwa: Going to Domenic's example, what is being labelled isn't any component, but the wholistic component
... There might be that we need some mechanism for the component itself to be labellable
... That's not a thing that exists today
Domenic: That's why I sad it's connected to custom form element propsoal
... That does allow things to be labelled
... I'm not sure how that interacts with what we have here
... I'm a form element, but I'm actually 3 input elements
... So I'm not sure ...
... Might be a simple design, or might be more complicated if you want to delegate to multiple
... But ...
Travis: I'd prefer to not design it here
Domenic: Does anyone have any interesting concerns we should note for a delgates- approach?
annevk: Do you need to decide up front if it's a fixed thing that you delegate to, or if it can change over time
... or is it event based?
Domenic: That's a good thing to note, that would drastically change design
Travis: Inputs do complex things like activation, etc.
Domenic: Simpest thing would forward evyerhing to that other element
rniwa summarizes into the issue.
bz: accesskeys are a smilar situation
... If accesskey is on shadow root, do we want a way to delegate the focus into the component?
Domenic: Maybe this is maybe delegates-activation, and labels focus activation, so it handles both
chaals: labels' also do activation
RESOLUTION: ISSUE 3219: This can be spec'ed using a delegation mechanism for a label or as a part of making custom element a form control.
tomayac: Also want to consider attributes that still use IDs
... There's still a concern that how we will delegate these label in the form conrol to the shadow root, still those properties of the label and control that currently uses stringified IDs needs to be somehow changed, right? To refere to actual elements
tomalec: for attribute HTMl for etc.
rniwa: In this world when delegation happens, you would be referencing noed in the same tree
... Label just references the shadow host
<annevk> Domenic, it sounds like another thing to take into account is that if label can lead to focus or activation and the target gets to decide, it needs to know the label was responsible
rniwa: Another one that came which we discussed birefly yesterday is the target links
... target names, window names
... the scopeof it
annevk: We had a solution for those
... Those are per shadow basically
rniwa: Any other issue sthat we misse dfor this topic?
<silence>
rniwa: OK, we move on.
<xfq> https://github.com/w3c/csswg-drafts/issues/556
rniwa: This is an issue form CSSOM spec, that they don't do retargeting
... I think this has quite a long discussion as well
hayato: The point is, when the result of ? is a tet node, we should return, but current spec returns ?
... So we try to fix that
fantasai: I think we have no active editor for this spec/
astearns: If anyone here would like to volunteer, I can make it official.
rniwa: So everyone thinks that we should fix this issue. There's one big question remainign in this issue
... Last few comments describes it
... In this example, wher eyou have div and shadow root, and div has child text node, and shadow root has a slot
... If this text node is assiged to the slot, then the way we would resolve the elemnt that this function returns, is to find the first ancestor element in the flat tree that does not have display: contents
... First one with a CSS box
... But tha'ts problematic in this case, but hten slot, which by default doesn' thave a CSS box, we would return the div
emilio: I think it would be if elementsFromPoint would return something that doesn't have a box
... I would excpect peopel to call elementsFromPoint and be able to start querying layout from there
... And don't want to break that assumption
rniwa: But if I called elementsFromPoint on this, I would have no idea about the shadow elements
... hayato's proposal was ?
hayato: I think it's the only solution
rniwa: I think if we wanted to make elementsFromPoint always return an element with a box, then we'd need a different method to get the nearest element with or without a box
Travis: ... use cases
rniwa: You could call elementFromPoint on the ? tree. I can't think of a case where you call it and get the host
... Even if we were to add nodeFromPoint, we'd have to say that elementsFromPoitn is broken in shadow trees
... We could just add them on shadow root or ..
emilio: Or we could make behavior different from shadow root or document
rniwa: ...
... special case text node that's assigne dot slot, return the slot, as opposed to od the normal computation ignoring display: contents
... In terms of computing a slot change event, and assigned nodes and assigned elements function . each slot element has option to ignore nested slot elements, so there is precedent for ginroing slot elements in an api
hayato: ....
... hit-tested, so we can create such a use case with shadow dom
rniwa: Not questioning the value of elementfromPoint
... But would it make sense ot special cae it n the shadow root
... Otherwise it'd be very annoying if there's a text node in the slot
hayato: ....
... Mabye should add parent element into slot, return the parent element of the slot
rniwa: They could wrap every text node in an element or every slot in an element, but hat seems awful
smaug: Can we just remove elementFromPoint and replace with nodeFromPoint?
<bz> fantasai: smaug
smaug: But if it's being used all the time on websites, then it's a problem
<bz> ;)
Travis: Maybe just remove that and find out what breaks
rniwa: Current behavior is very broken, so possible no one is using it
... if you call it you get nothing useful
smaug: Or slot is not used on text node
rniwa: But combination of this bug is very bad
... Any preferences to try one way or the other
... Could we tyr to remove it and add nodeFromPoint instead?
?????: Do you mean remove elementFromPoint generally? or just from shadow root?
hayato: There are several bug reports for elementFromPoint in shadow root
... So I think it would be difficult to remove as of now
rniwa: So we're going ot make the API terrible, and add a new one
... That does sound about right
hayato: We can add nodeFromPoint?
rniwa: Everyone agrees to add
Travis: If we know that elementsFromPoint is broken from shadow roots, we should patch that
... even if we have to special-case slot
rniwa: I would prefer a solution as well
... Special casing slo is not terrible
... I can sympathize that returning an element that doesn't have a CSS box is also weird
annevk: It's hard to think about since we haven't defined hit testing,
... If we had that algorithm i tmight be more clear
rniwa: Regardless if we define hit testing, if we hit the text node
... as an author I would want t get hte slot element
annevk: So if you get a text node back you get its parent
fantasai asks for clarification of whos's calling what
annevk: ?
hayato: ...
rniwa: There's a general idea that elementFromPoint wouldn't return elements with 'display: contents' in the general case
annevk: Why would we not do that here?
rniwa: If the shadow host doen's thave an element, then the element that it gets it would get something outside the shadow tee
annevk: It seems really weird to add a special case for this API and also add a different API
<hayato> The general issue is here: https://github.com/w3c/csswg-drafts/issues/556#issuecomment-430938131
fantasai: I don't see why you need a specal case here
... If you are the shadow root author, you could put an element around the slot to catch this API. Or you could make the slot not 'display: contents' by setting it to 'display: block' or 'display: inline'
... It doesn't make sense that the API which would skip all elements with display : contents elsewhere would not skip this element with display contents also
... If you want to capture elmenets with 'display: contents' you could add an option to the method.
... You might want to do this in other cases, too, e.g. if you have a <form> element you want to capture but you made it 'display: contents' for styling purposes
rniwa: So maybe the resolution here is to add an otpion to include 'display: contents', impelement what hayato and Tab propose, and add nodeFromPoint()
smaug: If ? do you get the host or not?
rniwa: You would get hte host
... You would do the same as closest check
... So everything outside the shadow root you get
+
+!
+1
Travis: I would be happy with that
<Travis> 👍
RESOLUTION: Add argument to elementFromPoint() to include boxless elements in the search, adopt hayato/Tab's proposal, and add nodeFromPoint() PAI
<br type=tea>
<xfq> [Break]
<Kelvin> Gamepad issues - https://docs.google.com/presentation/d/1B_W1rBbnAUce1VTjwOCeiDo98srSLYwBMYys_h2zh9w/edit?usp=sharing
github: https://github.com/w3c/webcomponents/issues/497
rniwa: Wanted thoughts
hayato: This is a mistake, we should definitely fix it
... Should not return nodes in shadow trees
...
bz: People use this for walkingall the way up to the tree?
rniwa: We have to use the retarget definition
hayato: We use the ? definition
<dbaron> bz: As long as offsetLeft and offsetTop etc. are relative to whatever offsetParent actually returns
emilio: Want to point out that htese APIs can be used to make layout calculations, and we would break those as you cross shadow tree boundaries
rniwa: Proposal is that if you call offsetParent we'd skip up, and then compute offsetLeft/Right against that node's containing block
emilio: That can still breaks stuff
... If you have a scrollable box in the shadow tree, and you jump above it
... Doesn't matter what offset you compute, it won't be relative to that node, and will do something really weird
... I don't know if they matte rin practice
plinss: Yes, they do
emilio: Across shadow boundaries?
annevk: To what extent are these the only APIs that expose those primitives?
... I thought all the offsetLeft etc. boundingRect
emilio: Offsets are exposed in a bunch of other places, but offsetParent is not
... There's no API for layout boxes
bz: Part of it is that the whole offset API is really weird
... Get a ancestor that satsifies funn yconditions
... People use this on the Web for lack of any other API
... Can get better results with getClientBoundignRect
... If we do this, certain code patterns would not give the right results if you cross shadow boundaries
... But we should just encourage people to not use these APIs
rniwa: So you think ...
bz: We obviously want offsetLeft/rgith/parent tow work as required
... But if people are setting for abspos, that's not going to work, and I don't see a way to fix that
rniwa: Your containing block could be things in the shadow tree, which could be any shape
... You cannotposition yourself reltavie to that
... OffsetParent ignoring parent is not that big issue, it already skips stuff
... Would we still use retargeting algorithm here?
emilio: Yes, there's not much else you can dod
hayato: This issue is just excluding the shadow tree in addition to closest media
(????)
<hayato> s/closed media/closed shadow tree/
RESOLUTION: Use the retargeting algorithm to find the offset parent, and the compute left and top from that node.
<xfq> github: https://github.com/whatwg/html/issues/3699
rniwa: This is an issue about directionality
... Suppose your document is rtl
... And your shadow root is LTR
... and you have a slot
... How do we handle directionality
hayato: We should use ancestor for consistency
emilio: This depends on how we resolve other inheritance issues with shadow trees
... because you can observe this with CSS as well
... You can call direction selector
<hayato> title attribute inheritance conclusion yesterday: https://github.com/whatwg/html/issues/3821#issuecomment-432978926
fantasai: This wouldn't be about inheritance of properties, just of directionality and language, which are not CSS properties
emilio: There've been some discussions of changing inheritance of properties in general, so you would not observe whether there was a shadow tree
annevk: What you're raising is that the CSS inheritance violates encapsulation
dbaron: It may be also worth separating the direction issue into multiple pieces
<annevk> https://github.com/w3c/csswg-drafts/issues/3248
dbaron: There's the content direction that CSS selects on, and then the CSS property direction
<florian> fantasai: this issue is specifically about the direction in the language, ie the content direction, not the layout direction controlled by CSS
fantasai: This issue is specifically about the HTML-based directionality and language, which are not CSS properties
https://github.com/whatwg/html/issues/3748
emilio: Issue ehre is that, let's say you have an element which has a shadow root and a child element which inherits from that explicitly, e.g. 'height: inherit'.
... If the parent has a shadow root, then you'd inherit from the slot element instead
... This has actually caused problems in browsers when they move elements to slot elements
... It makes UA shadow roots observable
dbaron: You used height: 100% as an example ...
emilio: You can observe from the computed value
rniwa shows off an exmaple from the issue
<florian> fantasai: this issue applies also for implicitly inherited properties as well
<florian> fantasai: you would just be less likely to reset them
emilio: If you do <slot style="color: red"> then the red is inherited to the children as well
... I'm pretty sure people rely on that as well, so it's tricky
hayato: Shadow tree has a full power of controlling hosts children rendering
... For example, it can directly be a ::slotted element
... or host children inherit style indirectly via slot element
... In extreme case, if shadow tree doesn't have a slot element, host children are not rendered at all
... So how host's childre are rendered depends on shadow tree
emilio: Only reason I raised the issue is that HTML spec defines stuff like details and summary in terms of shadow trees
... I'm not sure it wants to
... it violates the expectations of authors somethimes, that you can't inherit explicitly from the shadow node
dbaron: If you want content to not be observable, need to change nhertance
rniwa: Maybe you need a new CSS keyword that inherits from host element?
dbaron: I would avoid a new CSS keyword, but instead change how shadow trees are defined
annevk: Sounds like something that could go into the constructor, similar to delegates-focus
emilio: I'm a skeptical of changing inheritance to not work in the flat tree anymore
... So we have a very hacky way to do this thing for pseudo-elements in gecko
... pseudo-elements are coded to inherit from their originating element
... have to do special things to not break
... Flags like text decoration work over flat tree
dbaron: So the flip side is, we're here, trying to design a new feature as part of an issue that we looked at in reference from another issue, from another issue, so maybe we should pop the stack at some point?
emilio: I'm not sure we change how all shadow trees work
... but for HTML to change how shadow trees work or to not use shadow trees
rniwa: I think you raised earlier point, which is perhaps this issue of direction is separate from inherance
<florian> fantasai: that is explicitely… I do not want to do anything special with the css directional properties
<florian> fantasai: if the shadow tree is trying to be unobservable, if it can avoid setting inheritable properties, the only problematic case is when you use the inherit keyword, which should be rare
emilio: and you can set all: inherit on stuff if needed
dbaron: Is the main use case for non-observability here for the spec to over time define more things by this mechanism?
annevk: Implementations want to use UA shadow roots to implement things
dbaron: so specs and implementations, possibly at different rates
annevk: If the UA wants to maintain those invariants, web developers might wnat to maintain htem as welll
rniwa: Seems like if this is issue for UA, I see why it won't be an issue for some component authors
... So let's go back to direction/lang issue
... Seems like issue is that directionality and lang are specified in the light dom
... Let's say you have contact card, and using widget in your page, and your page is arabic, and you have contact names in arabic, it seems that the directionality of the text in that contact card that's pulled out of the light dom, should be left right to left, not ltr as the component dictates
<florian> fantasai: this is very specific about inheritance
<florian> fantasai: dir=auto can be set on anything you want, but it will not give the same result as explicit directions
rniwa: Talking about non-auto case
... If it has an explicit direction
dbaron: Explicit directions override inherited directions
<florian> scribe: florian
fantasai: but the declaration is at a higher level
... we want the direction that the author expects inherits through to not be broken by the shadow root
... the content in the shadow tree gets to chose whether wants to change the direction for its UI, but the content it pulls from the light tree needs to rest its direction to what it was in the light tree
<annevk> (I think rniwa said earlier that he agreed with me that UA shadow root concerns are concerns for web developers as well.)
fantasai: it does exist, we have to deal with that
... but authors are not expected to use it
... the HTML directionality also inherits, and the css properties inherit through the flattened tree, but the apply at a point where there content direction is already set
<fantasai> scribe: fantasai
dbaron: Where does shadow tree get direcitonality?
rniwa: inherits from shadow host
annevk: Assigned nodes also get it from the host
rniwa: fantasai's proposal is to do direction and language resolution in composed (but not flattend) tree
annevk: Easier to say that each tree has its own inheritance, and the special case is that the shadow root derives from host
rniwa: puting dir=auto aside
... One remaining issue is whether text node assigned to a slot
... would it maintain its direction
... so we'd have to inroduce such a concept
... in a shadow root it's possible to have two text nodes assigned to two different slots each which has a different directionality
<florian> fantasai: 1 text node gets to 2 different slots?
<florian> rniwa: no, 1 element, but 2 text nodes separated by a br
rniwa: You have 3 direct children, text <br> text
<florian> dbaron: that sounds bad
<smaug> Gecko uses composed tree, but inherits through shadom dom to have reasonable good compatibility with webkit and blink which use flatten tree
rniwa: the only way to assign is through default
emilio: Right now directionality is only assigned to elements, not to text nodes
... The closest ancestor in the flattened tree is the slot
... THis is the same problem that CSS had, that text nodes weren't defined to have any style
dbaron: We might be able to simplify by ignoring directionality on text nodes
... Content directionality only matters on elements, doesn't have an effect on text nodes
emilio: Because you can only select based on elements
dbaron: But separately there's the CSS dicretionality which we're not discussing in this issue
emilio: Directionality and text nodes should matter, because this case where you don't have an element ot inherit directionality from the host, then the text nodes would not inherit directionality from the host, effectively
dbaron: That is still a problem we need to solve
... But, part of what I'm saying is that we don't neecessary need to define ti by content directionality on a text node
... because content directionality on a text node can't do anything
<florian> fantasai: agreed
dbaron: So that somehow needs to be solve dthorugh CSS directionatliy
... Although CSS applied ot a text node has no effect
<florian> fantasai: you cannot have it apply unless ... even with the bidi direction stuff it has to be tied to an element with unicode isolate of embeded
<florian> fantasai: an inline that doesn't have unicode bidi on it…
fantasai: can't respond to 'direction' at all
<florian> fantasai: you can define it for elements, but for text nodes we don't know how to solve
<dbaron> It's not clear what we mean by wanting directionality of elements to derive from the host, since directionality has complex effects, e.g., if they're not establishing a new embedding level.
rniwa: So should we resolve that content directionality and content language are resolved individually in each tree?
<florian> fantasai: the content directionalily and the content language
dbaron: It's a reasonable tentative resolution that will probably do the right thing in most cases, but there are some messy things yet to work through
hayato: ...
... Maybe we can try to implement this in Blink, and if something is difficult we can give feedback.
rniwa writes in the resolution
RESOLUTION: resolve the content directionality and the content language of each element in each tree before flattening them except a shadow root's children will inherit its content direction & content language from its shadow host.
discussion of what to discuss next
<emilio> https://github.com/w3c/svgwg/issues/504
github: https://github.com/w3c/svgwg/issues/504
emilio: Issue is that as of right now, Gecko implements SVG2 model, which is a shadow DOM
... which means we match the elements inside the shadow tree
... But Blink/Webkit match the rules against referenced element outside the shadow tree, but give the style ot the element inside the shadow tree, and inherit as if they're inside the shadow tree
rniwa: So in blink/webkit so style rule for ocntent referenced by use element is evaluated where the content originally appeared, but then rules are applied in the shadow tree and inherit in the shadow tree
emilio: talks about his example
... SVG people wanted to do SVG2 thing, because it allows you to stye :hover and other states inside it
... We implement it, but wanted to ask feedback from other implementers whether they'd be willing to change their implementation
rniwa: I'm confused how this relates to shadow dom
emilio: ...
annevk: Use element is now defined in terms of shadow tree?
... That might not be clear to everyone
emilio: use is defined to clone the tree and apply the style sheets from the tree that it came from
annevk: Previusly it was a rather magical construct
... and that's what all non-Firefox impls have still
... I would assume that everyone wants to implement this because everyone wants to get rid of magical data structures
rniwa: Recall way that edge does painting of images and rasterization... if you odn't have DOM tree to match against, might have trouble there?
emilio: You can use less magic if you stop at ree your cloning with your selector matching
... Firefox initially implemented SVG2 model without a shadow dom implementation, this just cleaned it up
rniwa: So this is just an action item to make sure this is acceptable
emilio: I understand it not being a prioirty
hayato: We don't have any good person to answer this question
... In blink, there's no intention
emilio: In Blink only Frederick from Opera works on SVG stuff. I talked to him he was fine with implementing it as long as it doesn't break stuff
ewilligers: You can count him as Blink
rniwa: OK, so each takes an action item to look into it
Domenic: Hallway discussion, not a lot of agreement
<xfq> github: https://github.com/w3c/webcomponents/issues/468
Domenic: Google's position is that we'd like a mechanism that is not tied ot shadow roots and is custom element specific
... What we've found to work well is a cascading origin, as outlined in hayato's comment
... But Apple objects to this
... So sounds like we should take this offline, and develop as we can
... work with the CSSWG and so on
rniwa: One thing unclear is, what's the latest proposal
... Issue morphed into mega issue
... 5 different proposals right now
... Anyone want to state the latest?
annevk: The last comment ...
... Any special rules about selectors?
hayato: No special rules, just a new origin
... This addresses every concern in the issue
... We found this origin is very useful to address the concerns here
... It is the best way to address every concern
https://github.com/w3c/webcomponents/issues/468#issuecomment-432262227
emilio: Behavior-wise I agree that origin is the best way to solve this
... But if Apple can't do it, that's a problem
... Would like to talk to ? to figure out his perf concerns
... I would be fine with implementing such a proposal
rniwa: Our position is we don't want to have a new cascading origin
Domenic: we'll continue in incubation
annevk: Maybe talking with Antti might help figure out why?
rniwa: Probably better than asking me :)
emilio: It would also help satisfy my curiousity :)
...
fantasai: rniwa, if there wasn't a perf concern, would you agree that this is the best way?
rniwa: We worry that this will introduce more complexity for authors
... the important / non-important distinctionis confusing
... then have specifictiy interactions inside shadow root level
Domenic: It's helpful that your concern is with author confusion. That's something we can investigate with origin trials.
emilio: I think it would be even more confusing to mix shadow root style sand custom element styles specificity
rniwa: This is why we suggested that if there's a shadow root, we remove the style
... ...
... was supposed to be a lightweight mechanism to add a style
... not sure what you're trying to solve here
... Also weird that this was raised as a way to improve performance, but when we raise a perf issue you want to ignore it
github: https://github.com/w3c/webcomponents/issues/762
alice: I think it should be only for custom element API
github: https://github.com/w3c/webcomponents/issues/758
Domenic: Towards the bottom , converged on 3 ideas
... We had a lot of support for attachInternals() method (modulo naming)
... Do folks want to discuss different alternatives?
rniwa: Maybe it's good to go through each proposal
... First one is to have a new object like ElementInternals()
... to pass to super-constructors
... This would make an HTMLElement
... This is clean because only ? calls HTMl elements constructor
... But it's a weird pattern because can have code between creating newElementInterna() and calling superconstructor
... So bunch o issues like that
... So second approach is createdCallback(internals)
... Very different form ?
... This one you get an callback which is called by HTMLElement constructor
... Which creates a new customElement internals, and will ...
... And then element internals can modify the states
... Finally the last approach currently proposed is to have attachInternals() like attachShadow()
... Which would return and internals
... Raises concern about ????
... The proposal to fix the problem is to make this feature opt-in
... You would define a static element needElementInternals()
... And only if that is successful, would be able to attach
Domenic: The original proposal was an option to the define call instead of a static
... It takes an optional argument
... In case of attribute callbacks, there's .. static field which containst his list of attribute name
... And only call on attributes that are named in this list at the time of the call
... Anyone have opinions? Seemed like most people leaned towards last option last I asked
Travis: Is there an option where consturctor passes that arg in?
Domenic: No, because that breaks constructing your element with a ?
... As a user of the custom element, need to ...
Travis: Phantom parameter
Domenic: JS doesn't have those
👻
Domenic: Is the dientiy of the constructor ?
... Has a lot of plusses and minuses, but here it's a ?
... Doesn't allow the author to write ...
Travis: What are we doing with element internals?
Domenic: so many cool things
rniwa: Way for managing form control submission
annevk: Explain why like static better?
tken: ? and also, conserve the parameter version and created callback version look very weird and third one is easier to understand
<smaug> fantasai: FWIW, I think I can catch the most relevant information form the minutes.
rniwa: create callback has weird semantics because super function call
annevk: You said you don't care between static and option?
rniwa: there is precedence for attribute callback,
... ? is define don class itself
... so consistnecy with that might be good
Domenic: Why did we do that?
rniwa: So that the subclasses could inherit the value
slightlyoff: We've talked aobu this general design today
... Travis and Id discussed in the tag, thanks for filing for review
... warming to magical object, less concerns about how we get it
... but have meta-question about whether or not the current design epaisn enough
... original dom gives us attrs and properties, neither are private
... in other iplementations of DOM, have internal data that stores the data and has getters and settes
<annevk> (tkent did indeed not care)
slightlyoff: haven't described how this mechanism works
... I'm excited that this provides access to that internal state
... might simplify property attribute value mapping
... by describing storage for custom attributes/properties
?: General supprot
Domenic: So slightlyoff saying elementInternals is cool, but le'ts add more cool things
... such as attribute/property mapping
... There's nothing magical about it, it's just cumbersome
... but we should explore it
Travis: given classes don't have aiblity to store their fields, seems like a workaround
Domenic: it's a workaround for JS not having protected
annevk: Backto static vs defined, seems to be about inheritance
Domenic: I guess so
... And that does mean maybe static is better
... But I really don't like it ...
tomalec: I wanted to give small feedback on new callback
... My personal opinion on ergonomics
... Overall experience of my colleagues, they are already confused about constructor vs ? callback
... so adding one more would confuse them more
rniwa: So adding a new callback would be confusion?
tomalec: Yes.
... Too many things related to creation of element. Like 3 callbacks.
rniwa: So should we resolve on last proposal for now?
... Anyone have concerns?
Domenic: No concerns, yes, we should resolve
... I think we should also spend some time on the smaller bikeshedding issues, maybe not in plenary
... But what if we don' tmake progress for 6 more months, that would be sad
annevk: ARe there concerns with the current names?
Domenic: you're not really attaching it to anything
travis: What happens if you call it twice
... You might want ot retrieve it if you don't store it on ?
<florian> annevk: I like throwing
rniwa: If we make it retrievable, then anyone can retrieve internals
annevk: I think you should only retreive it once
rniwa: Want to make it hard for external users to get to this object easily
annevk: It's effectively the private state of the element
... simlar to shadow root being private implementation state
Domenic: Works well this way with combination of opt-in and call
... You have to have opted in, and not called attachInternas() to break
rniwa: If we don't like attach, could call it createInternals()
... coudl have mode liek shadow root
annevk: call it get
... esp if you call on an existing HTML element, it would have some internal state already
rniwa: How does browser differentiate subclass or not?
ewilligers: If you call it once, it's fine, if call it twice, it'll throw
annevk: It's associated with the instance, right?
Travis: I'd like TC39 folks to weigh in
... might have opion on how to do private state
annevk: this is protected state
Domenic: We should file something and see what they say
Travis: I'd like to have language support for something like this
Domenic: Not sure if there's a right in JS semantics, but we should check
rniwa: So that should be part of resolution? That we check with TC39 on whether they have opinions on how to expos protected state?
?: yes
rniwa: Are you ok to resolve and wait or block?
Travis: I'm supportive of Google experimenting to get developer feedback
... but not to code something up
Domenic: Yes, don't call it final
rniwa: So make this the tenative API
... And then wait for TC39 before ?
... OK, done with this issue
rniwa drafts comment summary
https://github.com/w3c/webcomponents/issues/758#issuecomment-433449099
github: https://github.com/w3c/webcomponents/issues/762
alice: It's going to come down to details
... Are we making a distinction between tabbable and focusable
rniwa: Need to be able to set that, though. Clearly needs to be configurable
alice: Yes, whether it's tabbable needs to be configured
... question is whether we make everything focusable and only things with tabindex are tabbable
Domenic: Currently suggest we have these two modes
... But alice says there's a simper version
alice: Do you opt into focus and sequential navigation separately or together?
rniwa: Input element is focusable
alice: focusable and tabbable
rniwa: Are there are elements that are focusable but not tabbable?
Domenic: That may be the question to answer before moving on
... I thought this was a platform thing
... There's aflag on MacOS that makes things more tabbable, but they're always focusable
rniwa: By default I can't tab through hyperlinks but I can focus it
alice: why are there elements that you can't call focus() on
fantasai: .focus() on a div?
alice: You can call it, but it's a no-op
rniwa: But we clearly need a distinction between focusable and not focusable
<chaals> bz: unless it is focusable
alice: Question is is this in sequential navigation or not
<chaals> s.no-op/no-op unless it has tabinex=-1
alice: I fail to understand why not programmatically focusable is a thing
bz: focusable is a side effect
... ...
... If you have a scrollable div which contains another div which contains text, you click on the text, if you focus the inner div and hit the arrow keys, what should happen if anything?
... The scrollable div is inthe tab navigation order in some browsers but not others
annevk: that's only keyboard-accessible, not through teh mouse
bz: Two questions about focusability: what can you focus with a mouse, and what can you focus progrmmatically
... i think right now those two concepts match
<annevk> (I said that in that specific example it'd be focusable by keyboard, but it'd be weird with the mouse.)
bz: But that is not required
rniwa: Making focus behavior change at this poitn might be backwards incompatible
alice: We then definitely need sequetially navigable and probably need focusable as well
rniwa: One thing I'm a bit worried is that when you specify that manually, people may not respect platform convention
... Suppose your ocmponent is for hyperlinks
... Do you know to not set tab focusable on Mac, becaue it can be focused on windows?
Domenic: Maybe instead of focusability, you set "behaves like a link" or "behaves like a button"
... We should give authors ability to match platform conventions
rniwa: If we added ability for custom form control
... We clearly need ability to make it match other form control
... But I'm a bit afraid that in other cases, because there is not such an equivalent semantics defned...
Domenic: I think we should give raw control but we should make it really easy to say "match this element"
... or this class of elements
bz: MacOS has "text boxes and lists", so select is always in the tab order, and various other things are sometimes in the tabl order
... But by default checkboxes and radio buttons aren't
tess: It's under Shortcuts, Keyboard prefs
Domenic: I don't think we can solve this right now
... we should keep in mind issue about matching platform conventions in our solution
Travis: Some folks at MSFT have done some investigation and made a proposal
... I'm just going to introduce, discssuion is in issue
... We want to treat HTML just like any other module that can be requested via improt system
... here example we import doc from "./module.html"
... It gets parsed into document format and returned as object doc
... Default import from an HTML file is the document itself
... In the next code sample, wyou cna get access to the content if you have script in your HTML page
... and the script wants to export something other than the HTML document by default, it can do that by re-importing itself
... and then exporting something separatel
... We had an idea that there would be import.meta.?
... But this is pretty slick, let's you grab yourself and pull it in
... sidesteps problems of import.meta
... that was suggested in discussion thread
... Final point is that what we do to the script elements we encounter as we parse them
... We treat all script elements as modules themselves, even if they weren't declared as modules
... so everything turns into a giant module graph
... Some debate in the issue which is issue 645
<Travis> https://github.com/w3c/webcomponents/issues/645#issuecomment-427205519
Travis: Question about whether we should do something different to mon-module <script>
slightlyoff: I love this
<annevk> Note that there's some parallel issues as well all labeled "modules"
slightlyoff: will help us avoid a lot of nested parsing issues with stuffing things into script
... This gives us rules for handling HTML
... which is our meta-bundling format
... Is there any thought on how to do this with other formats?
... like SVG or CSS or something?
Travis: We haven't put much thought into that
... Could certainly extend to support other markup
... and maybe CSS if there was something reasonable to et back
Domenic: Module system is straighforward, just need to define what gets export
rniwa: CSS is blocked on constructible style sheets
plinss: JSON would be nice too
<Zakim> Domenic, you wanted to say having spec text/prototype is great, will let us see what the answer is for tricky questions
<bz> +q
Domenic: This is super great, thank you for everyone who worked on this
... In particular, thanks for all spec text draft and the prototyping
... This is especially vaiable because whenever this topic ocmes up ther eare questions on how specific things work
... Base URLs, moving things between documents, etc.
... Mabye need ot dig through those issues
... With spec text proposal, we can just look and see what the answers are and see if we like the answers
... So action item is for us ot go back and see what the tricky issues were
... and evaluate the proposal wiht them in midnde
annevk: Do you have a specific MIME typetomalec
Travis: No
tomek: My main concern is ... from custom elements
... Because of using module,s all the custom element sdefine din thos emodule siwll flash with aunstyled content, because they will be upgraded after they are parsed
Domenic: We don't want to add more mechanisms for blocking scripts, Web has enough pef prolems already
... There are better solutions than blocking
... For example, display locking
... Which let's you block painting without locking the main thread
... There were some other solutions discussed using CSS, today's tech
... Recognize that this is a problem
... But very happy to do it not by blocking the main event loop as HTML imports did
bz: Inline scripts don't arrive until the parse is complete
Travis: Yes
bz: Excellent
rniwa: So each script in imported HTMl is parsed as seaprate module
<bz> Travis said: "that's correct"
rniwa: PResuambly this document doens' thave any browsing context
travis: I don't htink so
rniwa: DOM implementation and ? and you have a bunch of ocntent, and they are parsed as a script
... and run in document which is importing it?
Travis: Parser runs and creates a module, put in queue to be evaluated later
annevk: You can use XHR type ? , then antoher processing omdel which take s that document and does omething with it
Domenic: By leveraging module problem in a natural way, gracefully solved this problem
... Solves questions we had about execution
rniwa: You have HTMl document htat you fetched, and you collect each module, so you create the document first or get the module scripts because they're dependencies?
Travis: The scripts will be enocountered as eneveyrthing in the graph
... docuemnts will be parsed and given aout toeveryone who improted it and whatever they do to the document will ...
rniwa: so module documenent is the last hting in the module graph?
travis: well it can be anywhere in the graph
rniwa: Blank page with single script aht imports this HTML document
... The module graph, single graph that points ito that document, and all all those scripts in that document are second-degree dependency of the document
Travis: that's ight
<emilio> fantasai++
<hayato> fantasai++