- 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