- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Apr 2020 19:05:12 -0400
- 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.
=========================================
F2F Agenda Items
----------------
- There are currently only a few items tagged for F2F discussion.
Unless more items are added soon only one day will be set aside
for the virtual F2F.
W3C Website
-----------
- The W3C is planning to update their website. Anyone interested is
encouraged to participate on the wiki:
https://www.w3.org/wiki/2020_website_redesign
CSS Values
----------
- RESOLVED: Properties that accept quirky lengths accept number
token which is converted at parse to pixels (Issue
#4874: Quirky lengths and math expressions)
- RESOLVED: This resolution [above] does not apply to any quirks
inside of calc (Issue #4874)
- RESOLVED: Encourage SVG to follow this approach (Issue #4874)
CSS Text 3
----------
- RESOLVED: Let editors choose the behavior and mark this at-risk
(Issue #4893: Ogham Space Mark needs to disappear at the
end of a line)
- RESOLVED: Publish new WD of css-text-3
CSS 2
-----
- It may be possible to convert CSS 2 to use bikeshed. Anyone
interested is asked to review the github:
https://github.com/w3c/csswg-drafts/issues/2220#issuecomment-599873522
CSS Ruby
--------
- RESOLVED: Empty ruby containers are sized as if they have empty
things in them (Issue #4631: Size and position of empty
ruby level containers)
- RESOLVED: Margins, borders and padding do not apply to ruby base
or ruby annotation containers (Issue #4937: Be more
specific about the box model of base/annotation
container boxes)
CSS Color & CSS Color Adjust
----------------------------
- RESOLVED: Add mark, marktext, and buttonborder colors to system
colors (Issue #4924: We should add sufficient system
colors to fully implement the HTML UA stylesheet)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Apr/0012.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Dael Jackson
Brian Kardell
Peter Linss
Stanton Marcum
Myles Maxfield
Nigel Megitt
Anton Prowse
Florian Rivoal
Cassondra Roberts
Devin Rousso
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Rachel Andrew
Christian Biesinger
Scribe: dael
F2F Agenda Items
================
astearns: We need more tags on issues.
astearns: When I last checked we had 3 which is not enough for a
long meeting
astearns: At most we will have one long meeting at the end of the
month so we have something marked so people can put agenda
items on last minute
astearns: Unless there's more tags soon I can't justify setting up
more than one long meeting
astearns: Please come up with topics and we can schedule more.
AmeliaBR: Decision on a themed meeting or anything CSS is in scope?
astearns: Anything in scope. If enough issues are tagged that share
a theme we can do a themed meeting. That would be my
preference. Unless we get enough issues tagged for themed
meeting it'll be catch as can
astearns: Quick reminder
W3C Website
===========
link: https://www.w3.org/blog/2020/04/w3c-website-redesign-user-stories-brand-and-identity/
<fantasai> https://www.w3.org/wiki/2020_website_redesign/users
fantasai: W3C is trying to do entire website and they need more
input on the user story. A lot of people here are in
different roles. Please put requirements into wiki ^ so
design team can do a good job
fantasai: I'd like to invite anyone to re-organize or re-adjust
whatever is needed. That's about it.
astearns: Please take a look at the links and see what you can
contribute.
astearns: If there's anything about W3C website that has been
annoying to use please make sure those get mentioned.
fantasai: Complaints are it's hard to find things and hard to know
what exists. Nice if you can go to the website and find
what you're looking for, but don't know that unless know
what people are looking for
CSS Values
==========
Quirky lengths and math expressions
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4874
emilio: This is when should SVG and quirks accept numbers and when
shouldn't
emilio: I think quirks mode shouldn't accept calc but SVG is more
debatable.
emilio: Haven't checked issue today so don't know if there's new
comments there
astearns: One comment from Rune where he links to change list for
review on Blink
dbaron: I think what emilio is asking is the quirks mode rules that
you can omit pixels not apply inside of calc
TabAtkins: That's what I feel should be happening
TabAtkins: Effect of quirks mode is these properties are defined to
take number as final value and it's interpreted as pixel.
Has no effect on calc because doesn't allow 1 + 3px. If
your calc ends up as a number it works out.
TabAtkins: That's what some of the SVG properties do explicitly. If
we define quirks as same thing it's a nice consistent
system
emilio: Seems to be Peter said he didn't want it to work. A number
inside quirks not to work. I'm ambivalent.
florian: Logic is quirks was meant to be limited. This is logical
extension, yes, but quirks was meant to be as limited as
possible.
AmeliaBR: One complication is as we moved to typedOM and exposing
the true computed value not just resolved value things
could get a lot messier if we need to keep track of
numbers instead of lengths
emilio: I don't think any engine will struggle. Final number
interpreted as a length
emilio: I don't know but I suspect fancy calc rules would require
keep track but no one impl. You need math there. Calc that
resolves to number you can get final at parse.
TabAtkins: Not true with the later stuff
TabAtkins: Re-reading comments. Looks like you suggest quirks
accepts number token as the value. So write a literal
number but not any expression. No calc, attr, etc
TabAtkins: That's fine with me. Would like consistent with SVG but
since they didn't originally accept calc I suspect could
change
AmeliaBR: SVG presentation attributes where they accept values
allowed in regular CSS. Could define presentation
attributes are quirky
TabAtkins: Or just number token in grammar. Yeah
emilio: sgtm. Happy they're consistent
astearns: Proposal: In quirks mode properties don't accept calc
TabAtkins: In quirks mode properties that need to be quirky will be
specified to take a number token and interpreted as pixels
AmeliaBR: Spec when fixup happens? How it effect serialization/
computing?
TabAtkins: Don't know today
emilio: I think all serialize pixels.
AmeliaBR: I believe that's true
emilio: Almost sure webkit and FF do that
astearns: I don't expect the resolution effects serialization
TabAtkins: I could. Have to say when converts to length
plinss: Should be parse time. Quirks should be as limited as
possible and was designed to be phased out. Minimal impact
and just at parse time.
TabAtkins: Fine with me
<fantasai> +1 to plinss
<TabAtkins> Confirmed that Blink converts number to px at parse time.
astearns: Proposal: In quirks mode properties that are quirky will
be able to take a number token which is interpreted as
pixels
emilio: And so should SVG
TabAtkins: Different serialization rules, but otherwise yes
<dbaron> and the point is that "can take a number token" doesn't
apply any quirks *inside* of calc()
AmeliaBR: Not sure how much we need. Attribute value will get
attribute. CSS serialization can sync
emilio: We return pixels in specified side
<TabAtkins> proposed resolution: Properties that accept "quirky
lengths" are defined as having `<number-token>` in their
grammar, which is converted at parse-time to a px
length. SVG follows along for its presentation
attributes.
astearns: All one thing to resolve on? Or are there 3 bits to
resolve separately?
emilio: I think...browsers do not agree on quirky SVG so at least 2
resolutions
astearns: Proposal: Properties that accept quirky lengths accept
number token which is converted at parse to pixels
RESOLVED: Properties that accept quirky lengths accept number token
which is converted at parse to pixels
astearns: Second: This resolution does not apply to any quirks
inside of calc
<fantasai> +1
emilio: I think that's implied.
<fantasai> make it clear
astearns: I'd like to specifically resolve to make it clear
TabAtkins: Sure
RESOLVED: This resolution does not apply to any quirks inside of calc
astearns: Browser incompat and presentation attributes following
along. Can we resolve?
emilio: I've never heard of any compat issues
AmeliaBR: Don't expect issue on compat, but I have to open a
separate issue on SVG so we can resolve CSS endorces this
and we can add details on SVG
astearns: Proposal: encourage SVG to follow this approach
RESOLVED: Encourage SVG to follow this approach
CSS Text 3
==========
Ogham Space Mark needs to disappear at the end of a line
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4893
fantasai: Issue is that there is an Ogham space mark. Let me show a
pic
<fantasai> https://omniglot.com/writing/ogham.htm
fantasai: Written on the line. In paragraphs it's on the line.
Character called Ogham space mark
fantasai: When breaking lines should disappear at end of line.
fantasai: Wanted to add a rule you should drop final Ogham space
mark when trimming
<fantasai> https://github.com/w3c/csswg-drafts/issues/4893#issuecomment-613175286
fantasai: Question how to do that.
fantasai: Implication are about what happens when you mix spaces and
Ogham space marks
fantasai: Not likely to happen so it's what's easiest to implement
and we should pick that
<dauwhe> this book discusses the Celtic Tree Alphabet, which
apparently uses the Ogham script
https://www.penguinrandomhouse.com/books/575305/to-speak-for-the-trees-by-diana-beresford-kroeger/
florian: Main alternatives is at end of line you get rid of any mix
of regular and Ogham spaces. Or you do in phases. Remove
spaces, any Ogham left, you remove those.
AmeliaBR: Any other characters we treat as trimmable spaces for line
wrapping but aren't classified in collapsible?
fantasai: Not that I know of and this is the only one mentioned in
the report
florian: Tabs have been converted to spaces at that point
fantasai: Other visible word spacer marks but they don't disappear
at end of line
fantasai: There might be others
astearns: Any notion which is easiest to implement?
AmeliaBR: Any cases where the two algorithms have different effects?
fantasai: Different effects. You can see it in the comment linked
above
florian: I suspect two pass is easier to implement because you let
ICU do normal and then a second pass rather than hacking to
know about Ogham spaces. But I'm not implementing
fantasai: If no one on the call knows, please comment on issue. If
not I'll do whatever Koji says
fantasai: Spec wording is new and not entirely clear so I'll tighten
up a bit so it's clear
astearns: Any opinions?
astearns: We could resolve to do what koji says and mark at risk?
fantasai: Yep. Just say up to editors
astearns: Proposal: Let editors choose the behavior and mark this
at-risk
astearns: Obj?
RESOLVED: Let editors choose the behavior and mark this at-risk
Publication
-----------
astearns: Publication with this change?
fantasai: Let's just publish to get an updated draft. Some issues
left. Can do new WD
astearns: Does this publication need resolution?
fantasai: Yes
astearns: Proposal: Publish new WD of css-text-3
astearns: Not in CR?
fantasai: Not yet.
astearns: Should push to CR
fantasai: That's the goal. I've triaged. A couple of things need
comments. There's the whole removing break transformation
which we've drafted.
<fantasai> main open issue for css-text-3 is
https://github.com/w3c/csswg-drafts/issues/337#issuecomment-612686124
astearns: Objections?
RESOLVED: Publish new WD of css-text-3
CSS 2 Bikeshed
==============
github: https://github.com/w3c/csswg-drafts/issues/2220#issuecomment-599873522
astearns: Sam is convinced the bikeshed can be done. Here's the link^
astearns: Please take a look and weigh in. Sam thinks it can be done
so cool if they can do it.
CSS Ruby
========
Size and position of empty ruby level containers
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4631
florian: Spec doesn't say how to size if the containers are empty.
Size to 0 is bad.
florian: If they're empty want to be sizes as if contain empty ruby
base or ruby annotation
florian: Makes sense
astearns: Opinions?
astearns: Can you summarize?
florian: If a ruby base container or ruby annotation container is
empty should be sized as if contain an empty ruby base or
ruby annotation
florian: Empty thing container should be sized as if has empty of
that thing.
AmeliaBR: If both base and annotation are empty we still want
overall container to have vertical space?
florian: If you have ruby on an empty base you don't want ruby on
base of whole thing just in the ruby thing. You want ruby
to take the vertical space. If base container takes a base
you pretend it's empty and there
AmeliaBR: Like a strut that preserves line height for inline base
and annotation?
florian: Yes
florian: To remind people there's a ruby box that contains a ruby
base container that contains a ruby base and a ruby
annotation container that contains a ruby annotation. When
containers are empty they should not collapse to 0
astearns: Both empty containers and don't collapse so it's an empty
space?
florian: Yes but width of 0
astearns: Proposal: empty ruby containers are sizes as if they have
empty things in them
nigel: Point on not observable.
fantasai: It is observable if it's only content of line. Will
determine height of line
nigel: In inline direction...if you have ruby text that takes more
inline space than ruby base if can spill out. Does an empty
ruby base container effect flow of adjacent ruby text?
fantasai: You want to make sure things are paired correctly. Height
of annotation and base are contained so stack at correct
level. Don't want annotation to collapse to base
astearns: Purpose was to see if we should scope to if one of a pair
is empty it's sized as if empty but if both are empty they
collapse
fantasai: I don't think there's any precedence to do that. Inline
elements don't collapse to 0 when empty, they have height.
Should be consistent
astearns: nigel you okay with the side effects?
nigel: I was more concerned about width.
florian: I think this is about overhang?
nigel: Yeah
florian: 2 modes. One where you don't and one where UA does whatever
it wants. Given it's not spec this doesn't interfere.
nigel: I could imagine that and empty thing with size 0 has position
inline and that could overhang and effect adjacent things
fantasai: I think that's fine. The empty thing holds its place.
Should be expected. If you don't want it to hold it's
place it shouldn't be there
nigel: Feature. fair enough :)
fantasai: I think it's an edge case. I don't think there's anything
to worry about in terms of use cases
astearns: Good enough nigel?
nigel: yeah
astearns: Proposal: Empty ruby containers are sized as if they have
empty things in them
RESOLVED: Empty ruby containers are sized as if they have empty
things in them
Be more specific about the box model of base/annotation container boxes
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4937
florian: A little bit of imprecision about sizing and stacking on
ruby annotation and base containers. Both are positioned
and sized to contain all its boxes
florian: Ruby annotation contains margin boxes, but what contains
them? Should state. Then when we say they stack is that the
margin boxes or content boxes?
florian: Later in the spec in 3.2 we say these boxes when styled UA
not required to support margins and paddings and border
which make them observable.
florian: I believe what we're trying to do is margin, border, and
paddings are not taken into account for layout. Might be
for paint but for layout ignored and we stack content boxes
florian: Related in stacking direction we're ignoring so are they
also ignored in inline? They're not layout effecting visual
stylable boxes
florian: afaict FF almost does that. On margin, border, and padding
on both axis on annotation and base containers FF ignores
all except inline margins on base. Discussed with Xidorn
and he's okay with ignoring in all direction. Making them
abstract and not things that effect margins, borders, and
padding
florian: Is that okay and should spec be clarified?
stantonm: Confused. I thought desire to use margin to shift position
of ruby?
florian: Can on ruby annotation, but not on ruby annotation container
stantonm: Okay
stantonm: Fine to me
astearns: Other comments?
nigel: Question on PR.
nigel: The phrase "contains exactly" that's common language but a
bit confused
florian: I meant as in spec exactly. Maybe should fix that as well.
nigel: It is not linked as a defined term
florian: Open a separate issue to improve phrasing?
nigel: Will do
<nigel> -> https://github.com/w3c/csswg-drafts/issues/4950 "contain
exactly" should be a defined term
astearns: Proposal?
florian: The box that contains exactly the annotation box is the
content box. Boxes that stack are content boxes. Margins,
border, and padding on ruby box and annotation containers
does not effect layout
florian: Ruby annotation containers and ruby base containers not
ruby box
fantasai: It makes sense to say margins, border, and padding do not
apply to boxes. Shouldn't say they apply and don't have
layout effect
florian: There's a part of the spec that says for painting browsers
may or may not support. If want to shut down entirely
that's better
fantasai: Better because seems more consistent. If you can see them
why not layout effect?
florian: Trying to scope for time but makes sense
fantasai: Margins, borders and padding do not apply to ruby base or
ruby annotation containers
astearns: And the stacking content?
florian: If this is true it doesn't matter
astearns: Proposal: Margins, borders and padding do not apply to
ruby base containers or ruby annotation containers
dbaron: Run it by xidorn? Set of people that know this is small.
Maybe koji
florian: The first resolution was okayed by xidorn. Second part
matches current FF
dbaron: Okay with it than
astearns: We can come back if there's a problem
dbaron: Sounds good
RESOLVED: Margins, borders and padding do not apply to ruby base or
ruby annotation containers
fantasai: Another reason not to apply is people start to expect
effects and this lets us make adjustments in the future,
as they're less likely to have been used and thus cause
compat restrictions
CSS Color & CSS Color Adjust
============================
We should add sufficient system colors to fully implement the HTML UA
stylesheet
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4924#issuecomment-610662062
TabAtkins: Issue raised against HTML that UA stylesheet does not
respond to dark mode. What we specify in CSS does this
partially but it means that things like input colors
don't switch
TabAtkins: Results in bad design where inputs don't switch
TabAtkins: In issue discussion brought up these colors are specified
as literal colors and how should they be adapted
TabAtkins: Most straight forward is only use system colors.
TabAtkins: A few spots don't directly map to system colors. Argument
if you can't write UA stylesheet in system colors they're
not rich enough for web pages
TabAtkins: With this goal there's 3 missing colors
TabAtkins: The mark element needs text and background color to
distinguish from surrounding text. Right now it's yellow
with black text.
TabAtkins: Adding mark and marktext color
TabAtkins: Border of buttons and button-like things. It's a gray
between foreground and background. Could get around with
3d color things, but feel awkward and weird. Good to have
a color to offset from background. Button border color
lets us hit that
TabAtkins: Every other literal color use is well handled. Add these
3 colors and UA stylesheet becomes color scheme friendly
<dbaron> I think the existing system color set has two complete sets
of values for button border colors
TabAtkins: Proposal is add these and then we can proceed with HTML
issue. Better names welcome
AmeliaBR: Field as in text inputs also tend to have gray border in
UA stylesheets. It's not explicitly set out in HTML as a
color. Left to match OS conventions. Might be another
thing to add, field border. If field and button are same
perhaps can collapse
TabAtkins: That's not expressed in stylesheet
AmeliaBR: Neither is button border. It's in prose that must look
like button.
TabAtkins: Right
<astearns> we're talking about this list?
https://drafts.csswg.org/css-color-4/#typedef-system-color
<astearns> ah, and also this list:
https://drafts.csswg.org/css-color-4/#deprecated-system-colors
dbaron: Button thing. Is your assumption about how this color is
used within inset or outset?
AmeliaBR: Yes. Right now system colors from css 2 have
border-highlight and border-shadow but really impl as
single color plus inset border style which modifies
dbaron: Problem with inset and outset is they have an algorithm
which does not match system for button look. You won't be
able to match
TabAtkins: I think I'm still fine with spec having escape hatch of
similar to match OS. But a well defined color that does
the job is reasonable. Suggests you shouldn't have
blinding bright buttons in a dark mode
astearns: Do we have consensus on adding border color? Or just
resolve on mark and marktext?
TabAtkins: Not sure if dbaron is objecting or commenting
dbaron: Just commenting. If you're still okay I'm okay
astearns: Is border color for both buttons and fields?
TabAtkins: Definitely similar in HTML. For purpose of if you're
using system colors to do your own stuff using same color
is fine so I'd use one for both cases
astearns: Call it button color or different name?
astearns: button border
AmeliaBR: Resolve on button border and as people impl if they need
different color for field they can say
fantasai: Why not using the button highlight, button shadow etc on
the button?
<dbaron> I'd note that the ButtonHighlight and ButtonShadow colors
provide a one-color-on-a-side 3-D button effect, and the
existing ThreeDDarkShadow, ThreeDHighlight,
ThreeDLightShadow, ThreeDShadow colors provide a
two-color-on-a-side 3-D button effect.
AmeliaBR: They fall apart with stylesheet that's not creating 3d.
Which do you use. We don't want to preserve those.
fantasai: Wouldn't all resolve to same color?
TabAtkins: They're not implied to resolve to same. Implied to do
inset 3d-ish
dbaron: I think both sets of colors came from windows 95 system
colors.
dbaron: There was older set of windows where buttons had a single
border with a color in the middle color on highlight side
color on shadow. Newer went with two colors on each side and
had a separate set of names.
dbaron: button-something were the old one color on a side. 5 color
set that was 3d on newer windows and 3 of the 5 colors were
the same thing.
astearns: Happy to have border color without that baggage.
astearns: Proposal: Add mark, marktext, and button border colors to
system colors
astearns: Objections?
fantasai: Happy to add mark and marktext. Not clear on button. Are
we using button border in UA stylesheet or other stuff?
TabAtkins: UA stylesheet would say use button border for input and
buttons or match OS with similar intent. Neither 3 nor 5
color set matches OS conventions today. None of the
browsers will do it. But having something reasonable if
doing a generic system can be done with this one color
florian: Just because current design is flat or also true if we went
back to the days of glowing candy?
AmeliaBR: True if we go back to browser that have ability to do
lighter and darker accents using border-style
astearns: fantasai do you object to button border?
fantasai: Not objecting, concern about re-using it for hr and input
astearns: Objections?
RESOLVED: Add mark, marktext, and buttonborder colors to system
colors
astearns: Thanks everybody
Received on Wednesday, 15 April 2020 23:05:56 UTC