-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web Components F2F topics for 2018 TPAC #763
Comments
Selection handling + shadow DOM is something to figure out, #79 |
I think we need to have a consensus on: And other attributes: |
One more topic candidate: |
One more: Custom Elements Default Style |
@rniwa That link is to your own comment in this issue, I assume this was a mistake and you intended to link to something else? |
Yeah, fixed. |
https://github.com/w3c/webcomponents/labels/needs%20implementer%20interest are presumably worth discussing as well, in particular "CSS Modules". And then there's always all of these: |
Given how many topics we have to discuss, I suggest we schedule some time on Wed breakout sessions if we don't get an extra room on Tuesday. |
(Note that we have requested extra space if there is any... but there are no guarantees) |
Hi all, thanks to @LJWatson, we now have a room available on Tuesday in addition to Friday but the room for Tuesday doesn't have a teleconference capability. Do people have preference over which topic to be discussed on Tuesday (in-person only) vs. Friday (allows remote participation)? Please comment here ASAP. |
The space we have is for THURSDAY (9.00 - 13.30). Also note that it is a fairly small room (space for ~15, no phone bridge)... /@rniwa |
@chaals : Ah, okay. Thanks for correcting my mistake & clarification! |
I want to have a brainstorming session for "(better) Selection APIs for Shadow DOM" . |
@yoichio : Selection APIs for Shadow DOM is listed as a topic. |
Update: How should various document internal references work when SVG is being used in shadow DOM may need to move to Monday afternoon if Tab Atkins can't attend it on Thursday. If you have any concerns about this agenda change, please comment here ASAP. |
Let me share the brief summary of “Google’s position” on each topics of Web Components at TPAC 2018. Please consider this one-pager as just on-going efforts. Anything is not finalized, and can be changed, given recent increased discussion on several topics. |
https://bugs.webkit.org/show_bug.cgi?id=157437 <rdar://problem/26154021> Reviewed by Simon Fraser. Source/WebCore: Update the WebKit's treatment of shadow boundaries in offsetLeft, offsetTop, and offsetParent to match the latest discussion in CSS WG. See WICG/webcomponents#497 and WICG/webcomponents#763 The latest consensus is to use the retargeting algorithm (https://dom.spec.whatwg.org/#retarget). In practice, this would mean that we need to keep walking up the offset parent ancestors until we find the one which is in the same tree as a shadow-inclusive ancestor of the context object. For example, if a node (the context object of offsetTop, offsetLeft, offsetParent) was assigned to a slot inside a shadow tree and its offset parent was in the shadow tree, we need to walk up to its offset parent, then its offset parent, etc... until we find the offset parent in the same tree as the context object. Note it's possible that the context object is inside a shadow tree which does not have its own offset parent. (e.g. all elements have position: static) For this reason, we need to consider not just offset parent in the same tree as the context object but as well as any offset parent which is in its ancestor trees. Test: fast/shadow-dom/offsetParent-across-shadow-boundaries.html * dom/Element.cpp: (WebCore::adjustOffsetForZoomAndSubpixelLayout): Extracted to share code between offsetLeft and offsetTop. (WebCore::collectAncestorTreeScopeAsHashSet): Added. (WebCore::Element::offsetLeftForBindings): Added. Sums up offsetLeft's until it finds the first offset parent which is a shadow-including ancestor (https://dom.spec.whatwg.org/#concept-shadow-including-ancestor). (WebCore::Element::offsetLeft): Now uses adjustOffsetForZoomAndSubpixelLayout. (WebCore::Element::offsetTopForBindings): Added. Like offsetLeftForBindings, this function sums up offsetTop's until it finds the first offset parent which is a shadow-including ancestor. (WebCore::Element::offsetTop): Now uses adjustOffsetForZoomAndSubpixelLayout. (WebCore::Element::offsetParentForBindings): Renamed from bindingsOffsetParent to be consistent with other functions meant to be used for bindings code. * dom/Element.h: * html/HTMLElement.idl: Source/WebKit: Use *forBindings variants of offsetLeft, offsetTop, and offsetParent. * WebProcess/InjectedBundle/API/gtk/DOM/WebKitDOMElementGtk.cpp: (webkit_dom_element_get_offset_left): (webkit_dom_element_get_offset_top): (webkit_dom_element_get_offset_parent): Source/WebKitLegacy/mac: Use *forBindings variants of offsetLeft, offsetTop, and offsetParent. * DOM/DOMElement.mm: (-[DOMElement offsetLeft]): (-[DOMElement offsetTop]): (-[DOMElement offsetParent]): LayoutTests: Added a W3C style testharness.js test. * fast/shadow-dom/offsetParent-across-shadow-boundaries-expected.txt: Added. * fast/shadow-dom/offsetParent-across-shadow-boundaries.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@239313 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=157437 <rdar://problem/26154021> Reviewed by Simon Fraser. Source/WebCore: Update the WebKit's treatment of shadow boundaries in offsetLeft, offsetTop, and offsetParent to match the latest discussion in CSS WG. See WICG/webcomponents#497 and WICG/webcomponents#763 The latest consensus is to use the retargeting algorithm (https://dom.spec.whatwg.org/#retarget). In practice, this would mean that we need to keep walking up the offset parent ancestors until we find the one which is in the same tree as a shadow-inclusive ancestor of the context object. For example, if a node (the context object of offsetTop, offsetLeft, offsetParent) was assigned to a slot inside a shadow tree and its offset parent was in the shadow tree, we need to walk up to its offset parent, then its offset parent, etc... until we find the offset parent in the same tree as the context object. Note it's possible that the context object is inside a shadow tree which does not have its own offset parent. (e.g. all elements have position: static) For this reason, we need to consider not just offset parent in the same tree as the context object but as well as any offset parent which is in its ancestor trees. Test: fast/shadow-dom/offsetParent-across-shadow-boundaries.html * dom/Element.cpp: (WebCore::adjustOffsetForZoomAndSubpixelLayout): Extracted to share code between offsetLeft and offsetTop. (WebCore::collectAncestorTreeScopeAsHashSet): Added. (WebCore::Element::offsetLeftForBindings): Added. Sums up offsetLeft's until it finds the first offset parent which is a shadow-including ancestor (https://dom.spec.whatwg.org/#concept-shadow-including-ancestor). (WebCore::Element::offsetLeft): Now uses adjustOffsetForZoomAndSubpixelLayout. (WebCore::Element::offsetTopForBindings): Added. Like offsetLeftForBindings, this function sums up offsetTop's until it finds the first offset parent which is a shadow-including ancestor. (WebCore::Element::offsetTop): Now uses adjustOffsetForZoomAndSubpixelLayout. (WebCore::Element::offsetParentForBindings): Renamed from bindingsOffsetParent to be consistent with other functions meant to be used for bindings code. * dom/Element.h: * html/HTMLElement.idl: Source/WebKit: Use *forBindings variants of offsetLeft, offsetTop, and offsetParent. * WebProcess/InjectedBundle/API/gtk/DOM/WebKitDOMElementGtk.cpp: (webkit_dom_element_get_offset_left): (webkit_dom_element_get_offset_top): (webkit_dom_element_get_offset_parent): Source/WebKitLegacy/mac: Use *forBindings variants of offsetLeft, offsetTop, and offsetParent. * DOM/DOMElement.mm: (-[DOMElement offsetLeft]): (-[DOMElement offsetTop]): (-[DOMElement offsetParent]): LayoutTests: Added a W3C style testharness.js test. * fast/shadow-dom/offsetParent-across-shadow-boundaries-expected.txt: Added. * fast/shadow-dom/offsetParent-across-shadow-boundaries.html: Added. Canonical link: https://commits.webkit.org/207360@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239313 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Now we have 3-hour slot at TPAC.
We should gather topics which needs F2F discussion. I propose the following topics:
Please add more topics to this issue so that each browser vendor can have their internal discussion upfront (this seems to have helped a lot in the past).
@domenic @tkent-google @hayatoito @annevk @bzbarsky @smaug---- @travisleithead
The text was updated successfully, but these errors were encountered: