- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 12 Jan 2015 16:45:34 -0800
- To: Brian Kardell <bkardell@gmail.com>
- Cc: Chaals from Yandex <chaals@yandex-team.ru>, Anne van Kesteren <annevk@annevk.nl>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
- Message-id: <DE057BF9-82AF-469F-B928-1C086C941E8D@apple.com>
> On Jan 12, 2015, at 4:28 PM, Brian Kardell <bkardell@gmail.com> wrote: > > > > On Mon, Jan 12, 2015 at 7:23 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote: > >> On Jan 12, 2015, at 4:16 PM, Brian Kardell <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote: >> >> >> Sure, here are some use cases I can think off the top of my head: >> Styling a navigation bar which is implemented as a list of hyperlinks >> Styling an article in a blog >> Styling the comment section in a blog article >> Styling a code snippet in a blog article >> None of these scenarios require authors to write scripts. >> >> - R. Niwa >> >> >> I'm sorry, this might be dense but as use cases go those seem incomplete.... I believe you intend to illustrate something here, but I'm not getting it... Is the idea that the nav bar wants to deliver "this is how I am styled" without interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like "this is actually really hard to manage" with CSS and here's potentially a way to make it 'scope' easier? > > It's both that the navigation bar wants to have its own set of CSS rules and doesn't want to get affected by other CSS rules; and it's hard to manage a large number of CSS rules manually without an encapsulation mechanism like a style isolation boundary [1]. > > [1] http://stackoverflow.com/questions/2253110/managing-css-explosion <http://stackoverflow.com/questions/2253110/managing-css-explosion> > > - R. Niwa > > > Yeah, ok, that's what I thought you meant. Professionally, I come up with this case all the time and the number of cases where I want JavaScript ops to inadvertently poke into me is 0. Let's use your menu case, lets say that I have a class="title" on some menu elements and use id="main" - because, hey, that's one reason we like style isolation, we don't need to invent complex strategies. Fairly high odds that someone else in the page will qsa those and do something bad to me inadvertently. Having those respect the same boundary for the same seems very, very natural to me. I understand your use case but please also understand that some authors don't want to write a few dozen lines of JavaScript to create a shadow DOM, and hundreds of lines of code or load a framework to decoratively isolate CSS rules in their pages. > Quick note based on some of your other responses - I actually didn't see any proposal in the suggestions about TreeScope or a non-parent/child link connector or something that talked about insertion points... I think that is a secondary question, as is event retargeting? My comments are literally limited to the bare minimum stuff above without discussion of those. What questions do you have with regards with insertion points and event retargeting? Are you asking whether they should happen as a side effect of having a style isolation? I would just say that we feel event retargeting should be treated as a separate concern from style isolation. I'm denying that a style isolation with event retargeting is a valid use case but there are use cases in which style isolation without event retargeting is desirable or retargeting needs to be implemented by frameworks. - R. Niwa
Received on Tuesday, 13 January 2015 00:46:04 UTC