- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 20:58:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `What are the proper "levels" for managing "custom origins"?`.
<details><summary>The full IRC log of that discussion</summary>
<Rossen_> Topic: What are the proper "levels" for managing "custom origins"?<br>
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4969<br>
<myles> jensimmons: I like thinking of this practically. Bootstrap wants to use this, and it makes multiple custom origins inside of itself. This is given off to an author. As miriam and I were talking through, we have nesting, bootstrap has a file, and many imports, each one has a level as custom origin, then you put that into an author project, then an author project has its own levels, and that has its own nesting. That is just a lot of complexity.<br>
<myles> jensimmons: Maybe instead, it could be that each origin is in a separate CSS file. There's not a need for particular properties be in one origin and others in antoher origin within the same file. The files could be in its own origin, or multiple files could be in the same origin. This could be part of the <link> element<br>
<astearns> if we go with this idea then using the 'sources' name makes even more sense<br>
<myles> jensimmons: If bootstrap wants this, they would give you an HTML template that is a suggestion<br>
<hober> q+<br>
<myles> miriam: I've gone either way in that conversation. Advantages to nesting are that the final user gets some final control while other parts of the system can still use the tools. So a design system or at ool like bootstrap could have its own internal layering and a user could subsume those layers into their own project. That's a use case<br>
<fantasai> I think, we should think about this as all being in separate files for now, for simplicity. We can always add syntax for "embedding" such files into a document later once we figure everything else out. But should definitely be able to pull in the files through a CSS style sheet -- this is a CSS feature, not an HTML feature.<br>
<myles> miriam: It is clear that that interacts with how these would be set. IF they are only set in HTML there is no concern for the nesting. They're set at the final point of import or <link>. If we start allowing them to be set internally somewhere, then we have to allow the nested use case because it would not be good if bootstrap could create high origins and i have to fight their origins and we end up in a new battle over control. THe author needs final say<br>
<florian> q+<br>
<myles> miriam: Either they're set jsut there, or we have to handle the nested siguation<br>
<myles> s/siguation/situation/<br>
<myles> AmeliaBR: Which of these can be expanded on later?<br>
<myles> AmeliaBR: Having something that could be an attribute on <link> or @import or something like that, we could have that, and we could add an @rule later.<br>
<myles> AmeliaBR: I'm not sure how easy it would be the other way around.<br>
<myles> AmeliaBR: Another issue was about having a sensible upgrade path. That's related.<br>
<myles> AmeliaBR: How can we keep it simple to start while still adding the potential for new features if they turn out to be required.<br>
<TabAtkins> q+<br>
<florian> q- later<br>
<myles> hober: I wanted to echo something florian said. Fundamentally, this feature adds complexity in an area which is already complex and confusing. My inclination is to do the simplest possible thing. Regarding if there should be nesting, or sections, etc. The simplest that is possible is what we should do here. I like the file-wide, the entire file is one one origin idea. Should we be specify at @import time, and how tod o that, my inclination for simplicity wars<br>
<myles> with my inclination to not diverge <link> from @import. Those shouldn't diverge. If something can be part of <link> but not @import, that's a sign we've failed.<br>
<heycam> q+<br>
<Rossen_> ack hober<br>
<AmeliaBR> qq+<br>
<myles> hober: Where I'd like to end up is either some kind of file-wide delaration at the top of a style sheet and no change to any import mechanism, or an equivalent change to all import mechanisms, and no ability to declare it file-wide (only declared by the importer)<br>
<bkardell_> +1 to tess' points<br>
<faceless2_> +1 as well<br>
<fremy> qq+ too<br>
<Rossen_> ack AmeliaBR<br>
<Zakim> AmeliaBR, you wanted to react to hober<br>
<fremy> qq+<br>
<Rossen_> ack too<br>
<myles> AmeliaBR: To clarify, When I was talkin about @rule, I was talking like @supports or @media groups a bunch of declarations. I agree that <link> and @import should be functionally equivalent. That's not 100% everything in control of the HTML author, but we have a restriction on that saying that @import need to go at the top so there's a clear source order.<br>
<myles> fremy: I don't think it makes a lot of sense to put it on <link>. It makes more sense inside the document. All the sub origins you have and their order. That's different from each single file to add all these rules in one origin. Each CSS file should be able to put rules in each origin if needed. The HTML could add a <meta> tag to list all the origins. The stylesheet shouldn't define the origins. That should be in the HTML itself.<br>
<Rossen_> ack fremy<br>
<Zakim> fremy, you wanted to react to AmeliaBR<br>
<Rossen_> ack fantasai<br>
<heycam> q-<br>
<myles> fantasai: If this is a CSS feature it should be possible to do in CSS<br>
<myles> fantasai: It should be possible to link to a stylesheet and that pulls in everything that's necessary for the entire documetn. Everything we do should have CSS syntax.<br>
<heycam> q+<br>
<myles> fantasai: It might be possible to have segments of a single file in different origins. But now we shoudl think of them all in separate files beacuse we will need for that. Creating syntax for blocks inside a file will be easier if we figure it out at the file level.<br>
<dauwhe> q- ===<br>
<tantek> q?<br>
<Rossen_> ack TabAtkins<br>
<myles> TabAtkins: 1. Strong agreement with fantasai. All great stuff.<br>
<myles> TabAtkins: Regarding simplest possible. I generally agree with hober. We shouldn't overengeineer this for fanciness sake. But it needs to handle modularity sufficiently well.<br>
<fantasai> +1 to Tab<br>
<jensimmons> q+<br>
<myles> TabAtkins: Bootstrap needs to origin their own origins 0-6, and an author needs to work around that by putting code above or around it. But what if you're using two libraries? They will conflict and do something bad. SOme degree of nesting or scoping is going to be necessary unless we want to repeat the z-index wars again<br>
<dbaron> +1 to Tab on nesting<br>
<myles> TabAtkins: That will be a requirement for the final solution<br>
<myles> hober: <makes a joke><br>
<leaverou> If two libraries colonize the same origin space, would there be a way for the end user (author) to order these origins?<br>
<myles> miriam: It's worth remembering that in the discussion of complexity because flexbox is complex because people are using it to do grids. It's a question of "are we solving the problem." It seems less complex if we solve the problem<br>
<Rossen_> ack florian<br>
<fremy> <meta name="css-origins" value="reset bootstrap-reset some-lib-reset bootstrap-styles my-site-styles" /><br>
<myles> florian: Therea re two aspects to nesting. 1. Once the layers are in the right place, do we need nesting to do something useful interms of !important fighting itself or not. 2. Figuring out where they fit<br>
<dbaron> leaverou, I think that's the feature Tab was just saying is essential<br>
<fremy> ... then in the css @origin (bootstrap-reset) { ... }<br>
<TabAtkins> leaverou, yup, that's what I just mentioned<br>
<myles> florian: It seems to me that we might need nesting for the seond one but not for the first one. If bootstrap wants a bunch of layers, that's reasonable. The user of bootstrap doesn't need to know hwo the layers works. But we odn't need multple layers of !important interact iwth themselves and not wtiht the users' code. So, in teh end, you might not want bootstrap1, bootstrap2, etc. When someone imports bootstrpa, they decide boostrap is below them and they go<br>
<myles> on top, without having to worry about internals of boostrap<br>
<myles> florian: THis doesn't mean !importance of boostratp needs to be inside that<br>
<Rossen_> q<br>
<myles> florian: What we should be looking for is using nesting to figure out where the levels fit<br>
<myles> fremy: I don't like that because if bootstrap resets its styles, my library wants to put styles between those two, and that would be impossible in this idea<br>
<fremy> q+<br>
<tantek> What if Bootstrap's architecture is all by itself overly complicated and fundamentally broken? Optimizing/sovling for Bootstrap may be futile<br>
<Rossen_> ack heycam<br>
<myles> heycam: Responding to point about having an origin per file. I agree with hober and others who are saying it would be good to concentrate on something that's simple but extendable in the future if we find out we need thse complications.<br>
<tantek> I'd rather we make something simple that enables new developers to create something much easier to use that makes Bootstrap obsolete and abandoned.<br>
<myles> heycam: But for the origin per file thing, if we're following the fule that we should ahve CSS syntax for everything we do, then we just need to be careful to design some syntax that doesn't just apply to a file at the time, but is something liek an @rule that is self contained<br>
<tantek> s/fule/rule<br>
<tantek> s/ahve/have<br>
<TabAtkins> "Nesting" isn't necessarily the right concept here (that does imply that all the sub-layers go in one spot), but rather that the outer page can control where exactly a sub-project's layers go in the overall page's layer stack.<br>
<myles> heycam: It's common for bundlers to concatenate CSS stylesheets that get fetched over the network. We've seen problesm with that int he future. Something that clearly contains the rules in teh stylessheet is recommended.<br>
<tantek> s/liek/like<br>
<myles> Rossen: I agree.<br>
<Rossen_> ack jensimmons<br>
<fantasai> +1 TabAtkins<br>
<fremy> q-<br>
<myles> jensimmons: About making separate origins in separate files, if we don't do that, if we do allow segments of CSS in one file to be in diferent origins. Maybe we can name origins like variables, to explain how they act, or maye it's a set of numbers, the desire to keep it as simple as possible is good.<br>
<myles> jensimmons: If we just have one origin per file, we don't have to solve that problem. Instead, the ilness can be on solving this outside those CSS files<br>
<myles> jensimmons: What fantasai said about needing CSS syntax for all features is interesting though.<br>
<fantasai> TabAtkins, more specifically, I think a project should be able to control the stuff inside it, and the outer scope can't rearrange. But outer scope re-arranges everything it imports, with each direct import treated as atomic even though it may contain sub-origins<br>
<tantek> s/ilness/onus<br>
<TabAtkins> fantasai, Yes. *Possibly* with an ability for a project to project its layers into reorderable groups (like normal vs important, or reset vs actual, like fremy said), but that's probably more complexity than needed right now.<br>
<myles> jensimmons: Another thing that the frontend development world has create to create many files for keeping code organized and making it easier for multiple people to work on code, SASS has a technique that people use a lot where there's a main file where there's a file that lists other files. There's a meta file that lists the files. In a way that's what HTML is being used for. Perhaps we add osmething to CSS which is a manifest which describes other files<br>
<myles> jensimmons: The other thing is if we were to say no, you have to have separate files, and there is no concatenation, is everyone using HTTP/2? Because that's the reason build systems concatenate things to lower the number of HTTP requests. Not great for performance. Unless HTTP/2 takes over the world<br>
<myles> jensimmons: florian said what I was going to say. If nesting is allowed, does the nesting get flattened adn then delivered, or does it stay unflattened somehow. This is where the complexity for the brain-space in authors could get out of control. We all agree we want to avoid<br>
<Rossen_> q?<br>
<myles> jensimmons: We don't want a system wehre a team fo 40 people can't keep track of how things work because of nesting inside nesting inside nesting etc.<br>
<myles> Rossen: there's lots of progress on this issue<br>
<myles> miriam: I think we've covered a lot of the issues. I'd love if one or two people could help me flush them out from here.<br>
<myles> rossen: the one thing we need as a set of next steps is to write down some of the guiding principles that were used here, and use them as a guiding mechanism for designing next steps. Whether we're talking about how the origins or defined assuming they already work somehow and once this is done we can find how and where they interleave and interact<br>
<myles> astearns: It might be useful to have a regular meeting on custom origins for a while. One / month, once / fortnight<br>
<myles> astearns: The only topic is what the current issues are for this. So we can make some quicker progress.<br>
<myles> Rossen: sounds good. Like the "grid task force".<br>
<myles> 5 minute break! Then jump into the world of ruby!<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4969#issuecomment-622108162 using your GitHub account
Received on Thursday, 30 April 2020 20:58:19 UTC