{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/csswg-drafts/issues/2904","repository_url":"https://api.github.com/repos/w3c/csswg-drafts","labels_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/2904/labels{/name}","comments_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/2904/comments","events_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/2904/events","html_url":"https://github.com/w3c/csswg-drafts/issues/2904","id":340095009,"node_id":"MDU6SXNzdWUzNDAwOTUwMDk=","number":2904,"title":"[css-shadow-parts] consider moving part-mapping to style rules","user":{"login":"fergald","id":4255463,"node_id":"MDQ6VXNlcjQyNTU0NjM=","avatar_url":"https://avatars1.githubusercontent.com/u/4255463?v=4","gravatar_id":"","url":"https://api.github.com/users/fergald","html_url":"https://github.com/fergald","followers_url":"https://api.github.com/users/fergald/followers","following_url":"https://api.github.com/users/fergald/following{/other_user}","gists_url":"https://api.github.com/users/fergald/gists{/gist_id}","starred_url":"https://api.github.com/users/fergald/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fergald/subscriptions","organizations_url":"https://api.github.com/users/fergald/orgs","repos_url":"https://api.github.com/users/fergald/repos","events_url":"https://api.github.com/users/fergald/events{/privacy}","received_events_url":"https://api.github.com/users/fergald/received_events","type":"User","site_admin":false},"labels":[{"id":738999350,"node_id":"MDU6TGFiZWw3Mzg5OTkzNTA=","url":"https://api.github.com/repos/w3c/csswg-drafts/labels/css-shadow-parts-1","name":"css-shadow-parts-1","color":"c5def5","default":false},{"id":844839196,"node_id":"MDU6TGFiZWw4NDQ4MzkxOTY=","url":"https://api.github.com/repos/w3c/csswg-drafts/labels/topic:%20shadow","name":"topic: shadow","color":"009800","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-07-11T05:17:51Z","updated_at":"2018-07-11T19:19:13Z","closed_at":null,"author_association":"COLLABORATOR","body":"This came up in a meeting with Salesforce. It seems reasonable to consider this option.\r\n\r\nThe current [spec](https://drafts.csswg.org/css-shadow-parts-1/#partmap-attr) provides the partmap attribute to allow a part inside a sub-component to be stylable from outside the containing component. This means that forwarding rules are spread across many elements, e.g.\r\n\r\n```\r\n<x-bar>\r\n  # shadow\r\n  <x-foo partmap=\"inner outer\">...</x-foo>\r\n  <x-foo partmap=\"inner outer\">...</x-foo>\r\n  <x-buz partmap=\"buz-part\">...</x-foo>\r\n</x-bar>\r\n```\r\n\r\nAn possible alternative to that would be to include the part-mapping information in the style rules. There are several ways we could do this e.g.\r\n\r\n```\r\n<x-bar>\r\n  # shadow\r\n  <style>\r\n    /* this causes x-bar::part(outer) to match elements inside x-foo */\r\n    x-foo::part(inner) { @outer-name(outer) } \r\n    /* expose buz-part without renaming */\r\n    x-buz::part(buz-part) { @outer-name() } \r\n  </style>\r\n  <x-foo>...</x-foo>\r\n  <x-foo>...</x-foo>\r\n</x-bar>\r\n```\r\n\r\nAlternative ways of expressing this could be e.g.\r\n\r\n```\r\n@partmap myMap::x-foo {\r\n\tinner => outer; \r\n}\r\n\r\nx-foo {\r\n    @partmap(inner, outer);\r\n}\r\n\r\nx-foo::part(inner) { outer-name: outer } \r\n```\r\n\r\nGood points:\r\n- all mappings are centralized\r\n  - although they may be spread through multiple style elements inside the shadow root, so not necessarily centralized\r\n  - exposing the part name map via IDL is something we want, no matter how it expressed and anyone who wants to reason about the mapping should use that\r\n- can compress many repetitive partmaps into a single CSS rule\r\n- makes it even easier to emulate ::theme using ::part, each shadow tree can just do `::part(theme-name) { @outer-name()}` to expose all the theme-name parts\r\n- could also be used to add part names to elements, e.g. `.some-class { @outer-name(some-part) }` would be the same as adding `part=\"some-part\"` to all of the elements of class \"some-class\"\r\n\r\nPossible objections:\r\n- all mappings are centralized\r\n- these are not style rules, so should not be in the style sheet\r\n- unclear if there are implementation problems with this\r\n\r\nThis is a fairly radical departure from the current spec and if people think this is a great/terrible idea, I'd like to hear that quickly. I think there's no difference in what can be expressed in either case, the main points are:\r\n- the ability to expressing mappings for many elements in a compact form\r\n- centralized vs distributed\r\n\r\n[ Edited by @dbaron to change a file: URL to the https: URL for the spec. ]"},"comment":{"url":"https://api.github.com/repos/w3c/csswg-drafts/issues/comments/404281303","html_url":"https://github.com/w3c/csswg-drafts/issues/2904#issuecomment-404281303","issue_url":"https://api.github.com/repos/w3c/csswg-drafts/issues/2904","id":404281303,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNDI4MTMwMw==","user":{"login":"caridy","id":38969,"node_id":"MDQ6VXNlcjM4OTY5","avatar_url":"https://avatars1.githubusercontent.com/u/38969?v=4","gravatar_id":"","url":"https://api.github.com/users/caridy","html_url":"https://github.com/caridy","followers_url":"https://api.github.com/users/caridy/followers","following_url":"https://api.github.com/users/caridy/following{/other_user}","gists_url":"https://api.github.com/users/caridy/gists{/gist_id}","starred_url":"https://api.github.com/users/caridy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/caridy/subscriptions","organizations_url":"https://api.github.com/users/caridy/orgs","repos_url":"https://api.github.com/users/caridy/repos","events_url":"https://api.github.com/users/caridy/events{/privacy}","received_events_url":"https://api.github.com/users/caridy/received_events","type":"User","site_admin":false},"created_at":"2018-07-11T19:19:13Z","updated_at":"2018-07-11T19:19:13Z","author_association":"NONE","body":"thanks @fergald for creating the issue. There are few more things from the meeting yesterday that I want to highlight to give more context on why are we proposing this thing:\r\n\r\n* ergonomics: creating a new IDL for the `remap` attribute seems very limiting, and also suffered from some of the issues mentioned above, e.g.: users will have to learn that new syntax no matter what.\r\n* perf: it you move the remap info into a CSS, it is probably easier to cache the remapping (speculating here). At least you don't have to worry about the remap attribute reflection and mutation.\r\n* extensibility: in the CSS we have more room for experimentation with the rules (we have quotes, line breaks, etc).\r\n* equivalence: ultimately, users who want to have the remap in the place where they use the element can use the `style` attribute with the remap rules on it. (e.g.: `<x-foo style=\"::part(inner) { @outer-name(outer) }\">...</x-foo>`\r\n\r\nYes, there are some cons:\r\n\r\n* you need at least one style blob to do any remapping (I don't think this is a big deal).\r\n* decentralization since the style blob might reference things that are not longer in use by the markup (counter argument is the usage of the `style` attribute)"}}
{"actor":{"display_login":"caridy"}}