- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Nov 2022 20:29:44 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Text -------- - RESOLVED: Accept the text-spacing values for spacing adjustments? (Issue #6950: Make ideograph-alpha and ideograph-numeric part of text-spacing: normal) - RESOLVED: Non-zero padding disables text-spacing adjustment for spaces (Issue #6950) - A separate issue will be opened to handle space replacements (Issue #6950) CSS Ruby -------- - RESOLVED: Only perform whitespace stripping before comparing the base and annotation texts (Issue #5995: Should auto-hide match use NFKC and/or strip white space?) CSS Nesting ----------- - The group reviewed the new proposal for nesting outlined in issue #7970 (Yet another nesting proposal). Much like the other nesting proposals there was a wide range of opinions on if this was the right solution. It will be added to the page of proposals (https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md ) as well as considered as one of the options when author polling is conducted. CSS Tables ---------- - RESOLVED: Close the issue. Lack of interest. (Issue #7340: Allow 'order' on table columns) ===== FULL MINUTES BELOW ====== Agenda: https://github.com/w3c/csswg-drafts/projects/35 Scribe: fremy CSS Text ======== Make ideograph-alpha and ideograph-numeric part of text-spacing: normal ----------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6950 fantasai: text-spacing allows to adjust the spacing automatically at punctuation and between scripts fantasai: There are two values that adjust of add spaces between CJK and alphabetic characters fantasai: and between CJK and numbers fantasai: Typically, there is a little bit of spacing when this happens in practice fantasai: but this is not the current default behavior in browsers fantasai: The internationalization working group would like this to be the default fantasai: but there might be compat issues fantasai: so, maybe we will have to force authors to change the default if they want this florian: I think this is desirable florian: if you try making a book and you don't to this, you won't find a publishers florian: adding spans is possible but tedious florian: but compat can be problem florian: not really in paragraphs florian: but in buttons or menus, this might be an issue as the text might no longer fit tightly sized components florian: I hope I'm wrong, but I am concerned about compat florian: but I worry this might to be common unfortunately florian: but I don't know how to verify it astearns: JLREQ has a comment in the issue that says the behavior is desirable astearns: but that they understand the compat issue and are willing to accept 0-space as the default astearns: so, can we move forward here? fantasai: I think we should do this, and use the more conservative spacing fantasai: which will not change things too much by default fantasai: but we need to see if browsers are willing to do this, and how to handle any compat astearns: Is there any implementation willing to try this out? astearns: pdf processors would probably agree, but they area where the compat issues don't exist florian: Correct florian: Antenna House very likely has it, would be surprised if not heycam: So, is the experiment chaining the default behavior, and see if something breaks? fantasai: Doing it with text-spacing would be better fantasai: So we could disable it for a few elements, e.g. pre and code heycam: Webkit does not support the property iank: It's difficult to determine the compat risk iank: I worry that changing the default and then using UA stylesheets to opt out fantasai: No, only opt out special elements like <pre> and <code> fantasai: We would not want to opt out the entire page fantasai: Otherwise, I agree we should not fold it into "normal" iank: Okay heycam: Do you support text-spacing in blink? iank: No heycam: If no one has an implementation, then experimenting would require implementation first astearns: We could add a note that we are waiting for implementation interest florian: The issue is that pdf renderers will happily use the new default florian: and if we later find out it doesn't work for the web, we forked CSS astearns: We could have "auto" depending on the type florian: It's still a fork iank: Or we decide that print agents enable this in their user agent stylesheet PaulG: One usecase important to note, is AAC with "adapt module" extension makes things easier to read for other people PaulG: this might cause "script changes" that are not really true in practice PaulG: so this would affect their rendering astearns: This is likely true for people to have mixed scripts today astearns: and they will have double spacing if we change the default astearns: but they could detect and change <PaulG> the demo I mentioned: https://matatk.agrip.org.uk/personalization-semantics-explorations/module1-2020-01.html fantasai: Symbols and punctuation does not trigger this florian: If there is a span with padding, does the separation the padding causes text-spacing to be disabled? fantasai: We did not think of this yet, but we have other cases where we have some rules, so we could add one up florian: I think we should do it, so we don't cause double-spacing for existing content fantasai: Yes florian: I would still like browser implementations before going further, but I'm okay with just moving forward fantasai: Second point I want to cover, if there is non-zero padding we should disable this behavior fantasai: Third point, if you insert extra spaces to get this behavior today, we should take this spacing into account so it gets correct in the end florian: For CJK this seems rare florian: but for French, this might be something we want indeed florian: because you need a special space for some cases florian: but keyboards don't have the right keys so people use the wrong spaces florian: so we might want to replace them indeed (some discussion about keyboard being wrongs) astearns: Any objection to accept this? RESOLVED: Accept the text-spacing values for spacing adjustments? astearns: Any objection to the second point about paddings? RESOLVED: Non-zero padding disables text-spacing adjustment for spaces astearns: What about the third? fantasai: Let's do it too astearns: So, the suggestion is to take spaces into account at the boundaries? fantasai: No, replace it astearns: I think there might be cases where the choice is intentional astearns: Let's open a separate issue on that ACTION: Open separate issue on space replacement <RRSAgent> records action 1 fantasai: Maybe this shouldn't be a default, but something we can ask explicitly astearns: Let's go to 1 / 8 florian: Should we resolve on that? astearns: We should have an action for that florian: Up the editors astearns: Anything else on this issue? CSS Ruby ======== Should auto-hide match use NFKC and/or strip white space? --------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5995 fantasai: We have a feature in ruby where if the annotated text and the base are identical if they are presented on top of each other fantasai: but if they are side by side, they are kept for example fantasai: the question is "what is identical"? fantasai: Should we normalize before doing this? fantasai: Should we deal with white space fantasai: Should we collapse unicode characters that merge in rendering if possible? (NFKC) fantasai: but the internationalization group thought it might be too aggressive in some cases fantasai: They recommended NFC instead fantasai: which only deal with things that are simpler (e.g. A + an accent vs A accent) fantasai: so, do we want to perform NFC before comparing the texts? TabAtkins: I support whitespace stripping TabAtkins: because it can be due to source code formatting TabAtkins: but I don't think we should do NFC because we don't do this elsewhere TabAtkins: I expect that authors use the same typing convention in the same markup TabAtkins: we are not comparing html vs css florian: I agree about whitespace florian: for normalization, I'm less sure florian: if one persons types the text, and another the annotations florian: NFC is not very aggressive, I think it would make things more rational for users florian: however, it will be rare I think florian: but if it did occur, I think the correct behavior is to normalize florian: (so, preference for NFC, but not strong) <jfkthame> +1 to nfc astearns: Can we resolve on stripping whitespace, and leave off normalization? fantasai: I think yes, I agree with TabAtkins and Florian: it's definitely the right thing to do, but it's also not done elsewhere in the platform and is quite rare to mismatch fantasai: so it seems ok to drop this heycam: This is just a content check, correct? heycam: We don't look at display:none etc... ? fantasai: We might be looking at display:none? florian: but not generated content etc heycam: okay, hopefully the spec is very clear on that <astearns> jfkthame: would you be OK not doing NFC, or would you prefer we resolve to use NFC? astearns: reading IRC comments <fantasai> [note: those of us on the call are somewhat ambivalent about NFC, given pros and cons] <jfkthame> astearns: I'd be ok with not, though I think it's less good (sorry, in another meeting) <heycam> (I kind of don't quite understand the need for this automatic hiding, and why the author doesn't use visibility:hidden on ruby text that they know is the same as the base text) <fantasai> heycam, it's because whether it should be invisible or not depends on how it's styled <fantasai> heycam, and there's no selector for "this is the same text as the other thing" :) <heycam> ok <fantasai> heycam, plus it's what you want by default so we should do it by default astearns: Okay, since we have lots of doubts on NFC, let's just do whitespace and leave if at that florian: And also put an action on me to clarify the display:none behavior astearns: So, the proposed resolution would be to only perform whitespace stripping before comparing the base and annotation texts astearns: Any objection? RESOLVED: Only perform whitespace stripping before comparing the base and annotation texts <fantasai> "The content comparison for auto-hiding takes place prior to white space collapsing (white-space) and text transformation (text-transform) and ignores elements ( considers only the textContent of the boxes)." ACTION florian: make sure the way to determine what text we are talking about (display:none, etc...) <RRSAgent> records action 2 CSS Nesting =========== scribe: fantasai Yet another nesting proposal ---------------------------- github: https://github.com/w3c/csswg-drafts/issues/7970 plinss: This is something I've been wanting to do since the 90s, and immediately ran into problem of conflicts when nesting selectors inside a rule that expects properties plinss: I understand option 3 is trying to find workaround, and option 4 a different approach plinss: Wondering what if we turn the problem around entirely plinss: and introduce a top-level construct that only contains nested rules plinss: so never mix properties and rules in a single context plinss: My concern with Option 3 is that even if we have a syntactic way to disambiguous, that does paint us into a corner plinss: harder to introduce new things in the future plinss: My proposal is to introduce an @rule, calling @nest plinss: and inside that block is nothing but nested rules plinss: Can have no selector for a block, and that applies properties to the top-level selector plinss: No parsing changes, no extra lookahead, no changes to OM, easy to explain, no special bizarre syntax rules, just works plinss: Downside is you add an extra layer of indenting for properties that apply to top-level rule plinss: but I don't see that as a problem because I add extra blocks to code all the time, modern tools make this easy plinss: it's easy to see what happens plinss: I think this is much better than adding cognitive load to authors, learning weird parsing exception rules TabAtkins: As I said in issue, my objection is still that it requires a non-local edit TabAtkins: Can't just add stuff, need to go back and change the existing rule to allow nesting TabAtkins: It's a non-trivial bit of work, and is distinct from the way that every preprocessor has tried to do things since they invented nesting TabAtkins: Also, I continue to think that any statement about complexity of the rules for Option 3 is overstated, it's literally just "does the selector start with an identifier? if so need a prefix" TabAtkins: not that big a deal to learn or work around TabAtkins: Doing non-local edits to add nested rules to something is also a cognitive load when making edits in place TabAtkins: I don't like it TabAtkins: it does have better qualities than some other proposals TabAtkins: but it's roughly equivalent to just prepending @nest to all rules in terms of overall functionality, just changes where @nest shows up basically TabAtkins: That's been mildly rejected by authors and WG already, would like to avoid plinss: On the conflict issue, the point that you're missing is that mixing selectors and properties in one block does constrain us for future expansion plinss: if we ever want to put [missed] in a property block, we can't do that plinss: I'm very concerned about constraining our ability to expand CSS later TabAtkins: I share your concern. Still have some room for expansion, so I'm okay with it. E.g. if your expansion is after property name, can still do that; or if we introduce functional notations, we can still do that TabAtkins: neither of these would be parsed as a nested rule TabAtkins: so think there's still enough space for expansion, in my opinion plinss: Also, you can interleave properties and nested rules, how does that show up in the OM? Will lose that on reserialization plinss: my proposal avoids because can't do that TabAtkins: Assigning meaning to ordering seems fraught in first place, but it does mean when reserialize it'll look different from input plinss: No functional difference, but authors will order things for organizational reasons, and it's a loss to the author if lost on reserialization <astearns> In option 5 you can still interleave, I think `@nest foo { & {} bar {} & {} }` <plinss> astearns, yes, but the ordering is preserved because they're all style rules <astearns> ok fremy: I feel like there's a way of serializing this fremy: I don't agree that if you allow properties after rules it's meaningless fremy: it's same as selector with & only fremy: It affects ordering fremy: If your property defined after a rule doesn't work fremy: but that's a different topic, but it's something to consider fremy: Other than that, I feel like one positive point from plinss's proposal he didn't mention fremy: Shared with Option 4 fremy: It's ability to copy / paste fremy: If you nest with Option 3, cannot copy paste without running into problems maybe fremy: Both this and option 4 have this ability fremy: I agree that when you change from one rule to nesting, you have to add some stuff before/after, but I think it's worth mentioning that for Option 3 that if you go from nesting to not nesting or vice versa fremy: you need to change things fremy: refactoring is a pain in both cases, but it's different kind of paint fremy: but I wanted to mention this important point <tantek> copypaste++ and and also +1 for adding/removing nesting without having to rewrite the contents as a design principle argyle: I'm confused by the copy/paste scenario? I'm writing CSS using nesting 1, 2, 3, argyle: I copy paste stuff in and out of scope, in and out of ..., just use & everywhere fremy: You decided to use & everywhere, but if you remove nesting it'll break argyle: It only breaks with :has() fremy: That's not what I mean, what I mean is if you have a CSS file with a lot of rules, they can start with any selector fremy: html or p or whatever fremy: If you want to take all these rules and nest them, and say they only apply in this div with special ID fremy: you have to add & to selectors or they will break fremy: You can't just copy paste them into the brackets argyle: Concern in general, & makes it better and more clear fremy: Even if it was required, you would have to add these when you paste into nested context fremy: When you have a stylesheet with normal selectors, if you want to nest this stylesheet, you have to add & before every selector or it won't work argyle: I would like to see examples <fremy> stylesheet was " html { color: red } <fremy> if you want to nest this in #id <fremy> "#id { html { color: red } }" is not valid <fremy> you have to go and edit "#id { & html { color: red } }" <fremy> and you have to do that for potentially a lot of selectors Rossen: Sounds like some conversation paste each other, but 2-3 line example from fremy you will be able to see what he means about usability argyle: I've been using this stuff, it's not just theoretical argyle: I have 100s of lines of nested lines of CSS, I don't find a portability issue argyle: I don't see what you're talking about <fantasai> argyle, you're one of 50% of authors who think it's fine to prefix all their style rules everywhere forever with &. The other 50% of authors don't want to do this. <argyle> I'm in both camps, trying both... jensimmons: I really like this option, I like this a lot. I like it better than Option 4 jensimmons: what I would hope is that folks who've done a lot of work on this, and advocating to make this reality jensimmons: I hope that you are honestly willing to consider these other possibilities jensimmons: what's interesting about this is that it's a deviation from how web developers have thought about nesting from e.g. sass jensimmons: it is more like writing an @rule and doing stuff inside it, instead of having the shape from sass jensimmons: but I don't think we should reject out of hand jensimmons: there is something elegant of it jensimmons: and I think we need to think of the full range of people who write CSS, from students to hobbyists to professionals that write lots of JS to professionals that do other type of software engineering to professionals that do [missed] jensimmons: want it to be not breaking jensimmons: make it easy to understand jensimmons: think this proposal is very elegant and straightforward miriam: 2 things miriam: 1. This proposal is very much like @scope, doesn't have scoping aspects but otherwise the shape of it is basically identical to scope miriam: I don't know if that's positive or negative, but worth pointing out miriam: I agree with Jen about who we should think about, but also with Tab about how this seems problematic miriam: copy/paste is pitched as an advantage, but you're not able to copy/paste into something not @nest, takes a lot of adjustment miriam: All of these proposals have tradeoffs, and we keep fighting about which tradeoffs, and arguing which are better for authors miriam: I think all of theme are hard for authors, but we need to pick one fremy: I thought we agreed to make a survey and see what people think, but we now have another proposal fremy: but we should probably should do that Rossen: Agreed Rossen: Getting away from topic which is review of this proposal Rossen: Appreciate plinss for describing the proposal and its pros/ cons wrt others Rossen: My hope is that we'll get to next step and at some point will need to close the door on more options Rossen: and start scoping down which we will go with, which will work best for authors Rossen: with that, I want to move on... Rossen: but I want to simply take the conversation down to a closure with next steps being, let's figure out what people think about these options in a representative way Rossen: and then come back to making some choices jensimmons: I would really love for us to come to a decision, a final decision, by the end of the year. That might be a little ambitious jensimmons: I do think we're close. jensimmons: We could just decide on Option 3 and call it a day, but I think we do want to have a bit more debate about 4 or 5 jensimmons: but I also hear the clock ticking, so would like a decision by early January Rossen: Appreciate pressure and urgency, and hope we'll have something end of year or beginning of next Rossen: Ok, let's wrap up this conversation. Thanks plinss for bringing this up Rossen: One last closing question, do we have a path forward to organize non-biased survey, and who would that be? Rossen: jensimmons, can you do that? You seem most non-biased :) fremy: I think last time miriam, TabAtkins, fantasai and leaverou agreed to help plinss: I can edit the new proposal into the table <fantasai> there was a table in the repo <fantasai> -> https://drafts.csswg.org/css-nesting-1/proposals ACTION: plinss to update proposals table <RRSAgent> records action 3 ACTION: jensimmons, miriam, leaverou, fantasai, etc. to create survey <RRSAgent> records action 4 CSS Tables ========== scribe: JakeA Allow 'order' on table columns ------------------------------ github: https://github.com/w3c/csswg-drafts/issues/7340 fantasai: Question is whether to ask fremy to draft up a specific proposal for applying order to tables fantasai: would be restricted within boundaries of a rowspan/ colspan, can't shuffle those, but in any case we need a detailed proposal fantasai: and question to WG is do we want a detailed proposal <fantasai> -> https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415 Rossen: Opinions? fremy: I think it's a good time to think about it. I'll spend time in December working it - eg the table spec & this fremy: I think I agree. It doesn't feel like a huge amount of work fremy: I think this is a reasonable thing to do smfr: I think webkit has a low level of enthusiasm to do this. <dholbert> +1 to smfr, I have the same feeling RE Gecko's table code smfr: col order has semantic value. I don't think we'd implement this any time soon. PaulG: MS's spec for focus groups may be impacted by this PaulG: Different things may be correct depending on perspective Rossen: I see similar reservation from Mozilla iank: Q: Would this logic be pre or post col sizing? fremy: Before I guess iank: We have the newest impl right now. Our proposal would be fine. Table code is tricky due to legacy. iank: eg how do mergeable columns work? If it's like the order property in grid & flex, that's simpler iank: If it's pre sizing, it may have unintended effects on space distribution iank: If there's a simple way that's clean, that would be fine iank: Tables are complicated :D fremy: Can we move this to tables 4? That gives time for folks to reconsider. Does that make sense? iank: That's fine by me Rossen: Freshness of impl doesn't impact complexity due to legacy behavior. Rossen: Let's put it on the backlog. Deal with it later. Rossen: Legacy things aren't going to be removed before then Rossen: if anyone wants to reopen it, we can fantasai: we can reconsider it in the next level fantasai: The problem with closing it is it falls off the radar, and we lose context, if we don't want to actually reject it we should defer rather than closing. jensimmons: What's the usecase? We want to reorder the table without impacting the semantic order? Rossen: That's exactly where there's pushback. I'm in favor of closing. Objections? Rossen: Sorry, resolution? It's not a path forward we want to adopt Rossen: Hearing no objections. Let's close it, and not generate activities on it, that won't have impact. <jensimmons> Giving authors a way to more easily reorder columns & rows is something the web should do! But not in CSS. <fremy> @ jensimmons, I think I agree RESOLVED: Close the issue. Lack of interest. Rossen: Next week we'll have two calls. One in the morning, one regular time. One where we go through scroll timeline issues. Then later, the APAC call Rossen: Thank you for dialing in and getting up early / staying up late. Thank you!
Received on Thursday, 1 December 2022 01:30:25 UTC