- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 2 Dec 2018 06:25:39 -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 Cascade
-----------
- There were some preliminary proposals for how to only import
needed stylesheets, but the group discovered the scope of this
request was much bigger and could use more feedback from webdevs.
- RESOLVED: Move this (Issue #3050) to WICG.
Filter Effects
--------------
- RESOLVED: In mix-blend-mode, the default background color is also
painted within the page group. (FXTF Issue #282)
- RESOLVED: The filter applies to the result of the page group on
top of the root background color. (FXTF Issue #282)
- RESOLVED: clip path, opacity, mask will be applied to the output
of the page group on top of the root group. (FXTF Issue
#282)
- RESOLVED: The background color is UA defined with default being
white. (FXTF Issue #282)
- There is still more investigation to do around use cases for FXTF
Issue #53 (Backdrop filters should not use BackgroundImage).
Text Decoration
---------------
- RESOLVED: auto position resolves to the alphabetic baseline if the
offset is not auto. (Issue #3118)
- RESOLVED: text-decoration-width is now text-decoration-thickness
Next F2F
--------
- It will be in San Fransisco February 25th-27th
CSS Conditional
---------------
- RESOLVED: Create CSS conditional rules level 4
- RESOLVED: Accept selector feature functions for selector support
in @supports, accepting a single complex selector as an
argument. (Issue #3207)
- RESOLVED: Namespaces are either always valid or valid when they're
declared. (Issue #3220)
Selectors
---------
- RESOLVED: Name the selector [the “functional pseudo-class like
:matches() with 0 specificity”] :where (Issue #2143)
CSS Inline
----------
- RESOLVED: Add a leading trimming feature to the CSS inline spec.
(Issue #3240)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule
Scribe: gregwhitworth
CSS Cascade
===========
Import only in moment when we need it
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3050
TabAtkins: Did I add this?
TabAtkins: ok ok ok
TabAtkins: ah
TabAtkins: People want to only be able to import styles based on MQs
TabAtkins: but for reasons, we don't actually block downloading
TabAtkins: We have to go down the styles
TabAtkins: The web depends on them being walked
TabAtkins: So, people still want this
TabAtkins: Leave the downloads only for devices that need them, etc
TabAtkins: @supports is a good example of doing this
TabAtkins: The proposal - the two that I have are either a: keyword
like async after url()
TabAtkins: this indicates the stylesheet can be loaded async
TabAtkins: Or we can add a media function similar to supports, the
old will be forced function but this one will only occur
when the method is satisfied
TabAtkins: Does this seems like good possibilities, if so which do
you prefer?
myles: Kind of like device width, if you resize the browser it will
only fetch as you resize
TabAtkins: yes, it's bad to put it on things that are likely to
change
heycam: I think it seems reasonable to add support for this - the
media function doesn't seem like the best approach
heycam: for print I'm not even sure
heycam: You hit cntrl+p and having to print
heycam: Do you have any other scenarios
jensimmons: I'm very skeptical about this
jensimmons: I think it's a thing we want to think about deeply
jensimmons: There are many ways that people do to make it so that
it's faster
jensimmons: Some of them are terrible
jensimmons: Some of them make far more CSS, I'm not sure of anything
but we don't want to do it too quickly
jensimmons: Offering the tool - it will have a huge impact on how
people work with CSS
jensimmons: Now the industry is straining about CSS performance and
it's getting kind of scary
jensimmons: It's something we really want to explore - but we should
dig into all of the aspects and not ship too quickly
when the industry moves to a different approach that
negates the investments here
emilio: Why do we need to add import instead of link
TabAtkins: Right now link rel=stylesheet doesn't have async
TabAtkins: Whatever changes we have here we'll want to port over
there as well
jensimmons: You know what I might be saying is that I want to engage
with a CG with more webdevs
emilio: We rely on import, and others rely on that
emilio: ...
TabAtkins: One thing I'm running into - this might want to be, more
complicated
TabAtkins: rather than just @supports
TabAtkins: and import stays how it is
emilio: What is the context of why?
emilio: Why do we load print stylesheets even if we aren't printing
TabAtkins: The reason we do it now is because people expect this to
be the way it always has been
TabAtkins: Back in the day we didn't have promises for these types
of things
TabAtkins: This will avoid some of our issues
TabAtkins: This is getting more complicated - let's WICG it, let's
do what Jen said
TabAtkins: That sounds reasonable to me
emilio: There is a way to do this in webkit, the .disable factory
emilio: It won't load it
emilio: It feels like I've filed various issues on that
emilio: If we could agree on that - we could get web developers
ideas on it, no need for something new
TabAtkins: That functionality doesn't work on import
emilio: I was hoping to not have to do this on import
TabAtkins: Yeah we should though
emilio: We don't support all security on that either
TabAtkins: We should
RESOLVED: Move this to WICG.
Filter Effects
==============
What is the visual effect of filter() on the document element?
--------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/282
Rossen: This is about success on filters elements on the root element
chrishtr: I brought this a few months ago - there were a few pieces
of feedback
chrishtr: How do you treat the root element, in particular frames
that are transparent - similar to iframes
chrishtr: It's in a webview in side of an app for example
chrishtr: some other device that wants transparency
chrishtr: I did some more testcases
chrishtr: and have a proposed solution
chrishtr: The new proposal is that - there are two conceptual layers
you draw into, the frame root background layer
chrishtr: the root element layer
chrishtr: the background is always opaque white
chrishtr: So there is white and then the root element
chrishtr: You draw the stacking context of the root element into
that layer except the background is extended into the
infinite canvas
chrishtr: everything would apply as is
chrishtr: Clipping and filter and blend-mode and backdrop-filter are
done in the same order as before
chrishtr: So I went through the examples that smfr came out as he
expected
mstange: I don't think that is true.
mstange: In your root element layer there is no white background
mstange: If you don't have a background element on html then you can
apply and filter and it will break
mstange: If you have the background there then we will get what
Simon expects
mstange: We need to update background-blend-mode or we cannot invert
krit: Blend mode currently defines white to be the page's backdrop
mstange: Yes it does, but only the result of the blending is
composited on top of it - it doesn't participate
chrishtr: Is the contention - if you make it part of it then it
fixes the invert, but if you don't then it breaks it
mstange: If you make the white part - part of the page group you fix
invert but change how mix-blend-mode is defined
mstange: This part isn't implemented by Chrome
mstange: Correct?
chrishtr: I think Chrome is probably incorrect
mstange: But if we change it, Chrome doesn't need to change
chrishtr: True
krit: I want to change web pages that will always have the white
backdrop
krit: it is there for sites that didn't provide a background, is it
providing the background for websites
mstange: We still allow people to change the default color to the
background
mstange: There may be a11y issues here
chrishtr: Let's save that for a different issue
mstange: Sure
chrishtr: Do we want to consider white as part of the root
chrishtr: Then the root is not different than any other stacking
context
mstange: The filter may be opacity: 0 - you'll need some type of
result
mstange: I support painting the background twice, once inside and
outside of the page group
mstange: and defining the remaining issues
chrishtr: Why twice
chrishtr: Why isn't it ok to composite the filter to white?
mstange: That could work
chrishtr: You should just expect it to be composited to white
mstange: If we say it's white for now
mstange: If you want invert to be inverted
mstange: It needs to be painted in the page group
mstange: If you want a merge to apply to the default background color
mstange: The white needs to be present to the input of the filter,
now you have a result so you composite that to something,
what is under the result
chrishtr: It is white
mstange: That's why it needs to be twice
chrishtr: In the scenario where there is no background defined
Simon: You propagate the color to the root element layer, and then
do the composition
chrishtr: Yes
chrishtr: I think it's equivalent
simon: If the root is white with alpha
chrishtr: I think the math comes out the same
krit: Depends on the transform and color
krit: Let's say you can set the color in the page group, what would
happen? Would backdrop not get inverted?
mstange: FF settings don't allow alpha, the result would be opaque
and that would be composted onto white, always gives you
the same result
krit: My only concern - do we always have a solid color
mstange: As written, it would allow support for any background color
including no background color besides what is defined on
the root background color
chrishtr: Whatever the screen happened to have on it would be
composited
<mstange> proposed resolution: In mix-blend-mode, reword the
paragraphs "The page group is an isolated group. The page
group is composited with a backdrop color of white with
100% opacity." to mention that the default background
color is also painted within the page group, i.e. that
blending happens with the default background color.
Rossen: Any objections?
RESOLVED: In mix-blend-mode, the default background color is also
painted within the page group.
Proposed Resolution: the filter applies to the result of the page
group on top of the root background color
Rossen: objections?
RESOLVED: The filter applies to the result of the page group on top
of the root background color.
mstange: Your document also changes opacity, mix blend modes and
filter?
chrishtr: You mean it also changes opacity?
mstange: If you have a background red on root and opacity: 0
mstange: If I have background red on the root element, does this go
inside the page group and root group?
chrishtr: No
mstange: That changes what occurs - this does not change the root
element
chrishtr: This would change
mstange: opacity is a type of filter
mstange: clip-path and mask would change as well
mstange: If you have clip-path on the root element, the clip would
effect the background of red
chrishtr: I think that's good
mstange: I agree
Proposed Resolution: opacity, clip-path, mask and clip path will be
applied to output of the page group on top of the root group
mstange: I don't agree with clip
chrishtr: It's always a stacking context
mstange: Should we just not mention clip
chrishtr: Sounds fine
Proposed Resolution: clip path, opacity, mask will be applied to the
output of the page group on top of the root group
Rossen: Objections?
RESOLVED: clip path, opacity, mask will be applied to the output of
the page group on top of the root group
chrishtr: The reason I think we should use white as the background
is to provide consistency to authors
chrishtr: This is inconsistent with the need for a dark mode
krit: Why not just keep a weight
Simon: Why not have white be the default and allow UAs to adjust it
chrishtr: I'm fine with that
chrishtr: Should we ok with defining opaque
krit: We should define the UA may define the background color and
default is white
Simon: And it doesn't need to be opaque
Proposed Resolution: The background color is UA defined with default
being white
RESOLVED: The background color is UA defined with default being white
Backdrop filters should not use BackgroundImage
-----------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/53
chrishtr: For reasons of implementation complexity, number 1 and
avoiding situations developers would find confusing
chrishtr: I want backdrop-filter to only apply to containing
isolated group, which in spec terms is the background
image of the group
chrishtr: Takes the group - applies filter and then clips and paint
behind it and then paint on top
chrishtr: Issue 53, was originally filed to change the spec to not
image but all the images from the root
chrishtr: The prefixed impl that Safari has that draws everything up
to the root - and unprefixed version in Edge also has that
chrishtr: The reason I prefer it to the isolated group is because
it's easier to implement and more performant
chrishtr: Whereas if you draw all the way up to the root we'll need
to implement a new algo
chrishtr: If you go to an isolated group that is above the
containing isolated group you may have to take into
account other graphical effects into account with filters
that move pixels, etc
chrishtr: This increases complexity a lot
chrishtr: This makes it complicated for developers - there are a few
scenarios in the issue
chrishtr: There's an element with backdrop-filter, somewhere in the
ancestor an element has opacity but it isn't in the
isolated group but that opacity must be included - so
you're getting double opacity
krit: I have to agree that opacity is indeed strange, did you do
testing on Edge/Safari
chrishtr: Yes, there are screenshots in the issue and they do double
opacity
krit: I think there is developer desire to do it on the entire
section, not just the isolated group
mstange: Can you mention a case that would be impossible?
krit: When you do an animation that has a filter on it
krit: There wouldn't be any backdrop filter on it since it's
animating
mstange: That sounds like an animation issue
mstange: That sounds like an ordering issue
mstange: I agree with chrishtr that it would be easier to implement
and be more predictable for authors
krit: How does it work more consisted with mix-blend-modes?
krit: You have two divs on top of each other, the second would be an
isolation group - you would blend them together
mstange: Mix blend mode and isolation groups are not always the same
mstange: I'm interested in seeing scenarios in which I'm wrong
krit: or maybe I'm missing some
<krit> https://codepen.io/krit/pen/pxOMdz
[looking at codepen]
Simon: As I understand anything that creates a stacking context
creates an isolation group
Simon: That is contrary to the point of backdrop-filter which should
apply to everything behind you
chrishtr: Yeah
chrishtr: I think this needs more discussion offline
Rossen: OK, thank you chrishtr
<krit> mstange: https://dbaron.org/log/20130306-compositing-blending
Text Decoration
===============
Rethinking text-underline-offset
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3118
myles: We have two properties:
myles: text-underline-offset and text-underline-position
myles: [reads out values for each]
myles: Question is, both of these properties-
myles: the problem is only in horizontal WM-
myles: both of these describe the vertical position of the underline
myles: The spec does describe some situations on how they play
together
myles: What happens if they collide?
myles: There are two possible ways to solve this problem, is rules
and also to join them into one property and avoid the bad
issues at the syntax scenario
myles: I prefer the latter as it's intentional and mechanical
fantasai: I guess, I'm not sure which one is the better option
fantasai: The reason they were separated was due to position may be
dependent on the language where as the offset may be
author messing with it
fantasai: That means any time you want to make an adjustment you'd
need to provide the offset change and which side the line
is on
fantasai: That is mostly important in vertical text where the line
matters
drott: I think we still need both values, even if you combine them
drott: under auto | we still have to define rules when you combine
them
myles: Thinking of them as one as a position and as offset isn't
valuable because having an offset from auto isn't useful
because every UA has a different auto
myles: The pixel from the baseline to the underline is different
myles: We're in agreement here
myles: I do have a proposed syntax for this issue
fantasai: In the case of the conflict, over and from-font there are
three ways
fantasai: Treat from-font as 0, as auto, or to take the distance from
the alphabetic baseline and compute that to a pixel
myles: You mentioned three of them
myles: Two of them, pick a winner
myles: Third is typographically bad - because it's defined to not be
applied anywhere else
fantasai: Before we add another keyword
fantasai: There are whole lot of complications with underlines
fantasai: When you have inline elements that have different font
sizes the position of the underline gets complicated
fantasai: If they're aligned alphabetically you're at least setting
them from the same offset
fantasai: But if text is aligned along the central baseline you
don't want the line crossing through the chars
fantasai: If you use under, you need to go below the largest
descender and those calculations aren't tightly defined in
L3 and we need to think about it for L4
fantasai: I want us to be thinking about it
myles: Are you referring to the decorator box
fantasai: Not sure which one is that, but you don't want to cross
through text - the UA should be taking the descendants
into account
myles: ok
fantasai: Not sure where that brings us on this topic
drott: can you sketch out your syntax proposal
myles: I can link to it
<myles> https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-421827968
fantasai: Easiest for combining is auto | from-font | length
koji: How you set position of underline
myles: No opinion - defer to fantasai
fantasai: The offset measures in the block axis, so it works fine for
vertical text
fantasai: If the line is on the ascender side it goes away from the
alphabetical baseline based on the value
drott: Do we agree that the from-font should not be used for
vertical text?
fantasai: I don't see why not?
drott: So we do want to use it as well?
drott: The second point here is a bit inconsistent because we had
from-font only for offset value and here it's for a base align
drott: Here it's changing baseline left is equivalent to position
before
<fantasai> auto | from-font | [ under || [ left | right ] ||
<length> ]
fantasai: Actually I think there is something we can do
fantasai: Move from-font to the other property
myles: So it will clobber the other
myles: Would it be added?
fantasai: from-font + a length?
fantasai: You get the offset and then it's added to the length
fantasai: I want it shifted down more
myles: So would auto mean 0?
fantasai: Auto currently means what the UA does?
myles: The property that takes the length
fantasai: I'm not sure if the offset for left and right is 0
fantasai: If the UA does not hide the metrics of top or bottom, left
or right
myles: Underlines are exactly on the bottom of the descenders
koji: What about when the issue is on the baseline?
fantasai: You're right we would have to do that
fantasai: The underline might be 0, but the alphabetic baseline
there would be an offset that is UA defined
fantasai: Auto means the UA gets to define what is appropriate
myles: You said they add
fantasai: We can't have an offset of 0 go from a UA-defined position,
it needs to be exactly on the baseline or the author has
very little control
fantasai: The offset needs to be absolute
fantasai: Underline position is something that folks will primarily
use in CJK, for vertical underlines
myles: So if both are auto it will look good, but if you set it to 0
it jumps up
fantasai: Yes
Rossen: So what do we resolve on?
<myles> auto | [ [ under | from-font] || [ left | right ] ]
myles: The grammar of text-underline-position turns into this^
<myles> auto | <length>
myles: The grammar of text-underline-offset is this^
koji: Yep
fantasai: Yeah I think that's right
drott: And the behavior if the value is from-font and then a length
with offset they are added?
fantasai: Yes
myles: So if position is auto or from-font then they add
fantasai: No they always add, but auto resolves to the alphabetic
baseline if the offset is a <length>
Rossen: Any objections?
RESOLVED: auto resolves to the alphabetic baseline if the offset is
not auto
text-decoration-width
---------------------
myles: this is text-decoration-width
[myles shows presentation]
myles: We wanted to be consistent with other things, but the purpose
of consistency is easy of learning, and people are clearly
confused, so I propose text-decoration-thickness
RESOLVED: text-decoration-width is now text-decoration-thickness
Next face-to-face
=================
scribe: mstange
TabAtkins: Last week of February, 25th-27th
TabAtkins: Same building as last time
TabAtkins: San Francisco's February weather isn't the best but
better than San Francisco's summer weather
TabAtkins: TGIF uses that floor on Thursday, so we only really have
half the day
TabAtkins: Monday to Wednesday are the only days we can use it
usefully
Rossen: Are we not doing houdini topics?
TabAtkins: Don't have any plans, expect to do a half-day side-track
during CSS for anything we need to discuss
CSS Conditional
===============
Selector feature query function for selectors
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3207
dbaron: When we discussed @supports back when we originally did it,
one of the things we talked about that we maybe want to have
support for more than querying for values
dbaron: There may be more important use cases
dbaron: Next addition would be testing for selectors
dbaron: If you have three comma-separated selectors, the entire rule
is supposed to get dropped if any of them is unrecognized.
dbaron: This is painful because you don't get good negation
operations.
dbaron: It has also come up recently when looking at scrollbar
styling.
dbaron: @supports is useless for existing scrollbar styling use cases
dbaron: because some of them use selectors
dbaron: We all agree on what the syntax of testing for selectors
should be, which is, it should be a function called selector.
dbaron: We want to allow combinators.
dbaron: There are currently some quirks related to ::-webkit pseudo
elements
dbaron: There is a quirk that makes all ::-webkit pseudo elements
not invalidate the selector
dbaron: We do not want to carry over this quirk to @supports selector
heycam: There is an open question about namespace testing
<myles> https://bugs.webkit.org/show_bug.cgi?id=189089
dbaron: This turns out to be a bug in existing @supports because we
didn't define it for content: attr(?)
dbaron: We should figure out how it interacts with @namespace prefix
declarations
TabAtkins: I'm fine with not having them
TabAtkins: I definitely do not want to look at namespace, should
either fail or pass always
fantasai: I agree
dbaron: I would lean towards saying the always succeed and act as
they always match the namespace
emilio: I would like to argue for the opposite, we should actually
look at the namespaces in the stylesheet
emilio: If you are testing for a selector that you actually use
inside your @supports rule, that's what you want.
emilio: It also doesn't require any special cases in the
implementation.
plinss: Isn't that the point, to ask whether you support "this type
of selector", not "this particular selector"?
emilio: I would argue that if it's an unknown namespace, you should
not go into the @supports rule
emilio: Invalid namespaces are invalid, they drop the whole rule
emilio: just doing syntactic checking is inconsistent with other DOM
APIs that throw on invalid selectors
emilio: Like .matches
TabAtkins: Can we make them always invalid?
emilio: I'd prefer that over making them always valid
dbaron: There's a risk with newly-supported selectors in the future
emilio: Please don't introduce a special case
TabAtkins: The matches function always ignores namespaces, because
it always throws when there's a namespace
emilio: Because there's no stylesheet
fantasai: There's a rule in the :matches() spec that talks about
namespaces, but it doesn't make it invalid
dbaron: The other thing about the selector functions is that at some
point the drafts of those functions had a namespace argument
that got dropped.
heycam: With CSS prefixes on the DOM node, no namespace prefixes are
going to succeed except * or |
TabAtkins: That same behavior seems fine to have for @supports
fantasai: That doesn't make sense
fantasai: I want to check whether I support a selector. Any selector
that I'm using in my stylesheet, I should be able to put
it into @supports
emilio: I agree.
fantasai: Which is not what TabAtkins is saying.
fantasai: .supports would still return "yes I support namespaces"
fantasai: it's not about "Does querySelector" support this
fantasai: We're checking things at the syntactic level
fantasai: I'd be ok with checking the namespace whether it resolves
emilio: I would prefer to look at the namespace map, if it's around
emilio: Then we don't conditionally need to make all namespaces
valid in some cases.
emilio: The rules in @supports should be the same rules as for
regular parsing.
TabAtkins: What do you think about changing the regular parsing rule
of "bad namespaces" kill the rule?
futhark: I tend to agree for regular namespaces. If we're not
checking namespaces, I prefer that we actually allow
namespaces.
emilio: So either check the namespace map as normal, or always
succeed.
dbaron: We need another resolution first, which is to create level 4
of CSS conditional rules
dbaron: unless we want to put this in level 3
RESOLVED: Create CSS conditional rules level 4
RESOLVED: Accept selector() feature functions for selector support in
@supports, accepting a single complex selector as an
argument.
dbaron: Do we want a resolution or two about the namespace thing?
<heycam> the namespace prefix issue is
https://github.com/w3c/csswg-drafts/issues/3220
fantasai: For the namespace we've resolved that they're not always
invalid.
RESOLVED: Namespaces are either always valid or valid when they're
declared.
Selectors
=========
Name the “functional pseudo-class like :matches() with 0 specificity”
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2143
<fantasai> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-408128027
fantasai: Lea is not here, do we want to talk about it?
fantasai: Anybody have anything to add to this discussion? There's
no clear "this is definitely what we should do" resolution.
fantasai: This takes a list of selectors of which any can match.
Unlike the :matches() selector it basically zeroes out the
specificity: anything you put inside has a specificity of
zero.
fantasai: This gives you more control about which parts of the
selector affect the specificity and which don't.
fantasai: The only question is what to name it.
fantasai: Some of the suggestions didn't get any traction.
fantasai: We don't have any suggestion that is clearly better than
the other ones.
fantasai: My concern with a lot of these is that it is not very
clear e.g. for :if() or :where() why this is different from
:matches().
fantasai: It's different because of the zero specificity, so the
name should have something to do with that.
franremy: Last time we had narrowed it down to three.
fantasai: New ones were added after last time.
franremy: We almost agreed on one of them last time, don't remember
which one.
franremy: Would prefer to not expand the length of the list of
candidates.
dbaron: To make progress, we need to say "Nobody leaves the room
until we decide."
<ericwilligers> Last time: :if() vs :where()
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0027.html
fantasai: Our resolution last time was to narrow the short list to
:if() and :where(), and since then people also suggested
:nil() and :zero().
fantasai: So we could choose between those.
<iank> :quash()
Rossen: (1)if, (2)where, (3)nil, (4)zero, (5)quash
Rossen: In that order, go ahead and put in your preferred 3.
Rossen: In the order of preference
* jensimmons doesn’t know what this does
<franremy> 1 2 ... 4 3 5
<iank> 2, 5, 3
<fantasai> 5, 3, 4, 1, 2
<cbiesinger> 2, 1
<florian> 1, 2
<TabAtkins> 3, 2, 1
<heycam> 2, 1
<futhark> 2 3 5
<dbaron> 4 3 2 5 1
<ericwilligers> 2, 1, 4
<Rossen> 2, 1
<eae> 3 2 1
<melanierichards> 2
<AmeliaBR> 2 4
<rachelandrew> 2, 1 , 3
<emilio> 3, 1
<Oriol> 1, 2, 4, but I would prefer any
<tantek> 4 3 5 :ns (no specificity)
<fantasai> https://github.com/w3c/csswg-drafts/issues/1170
<AmeliaBR> Why was `:is` dropped from the options?
Rossen: A lot of votes for number 2 as the first choice
Rossen: Resolve on :where()?
Rossen: If anyone has a strong reason to change this, speak up now.
RESOLVED: Name the selector :where()
CSS Inline
==========
Leading Control
---------------
github: https://github.com/w3c/csswg-drafts/issues/3240
fantasai: On that page you see some diagrams that Jan and Niklas
sent me.
fantasai: The problem we have in CSS that is driving a lot of
typesetting people crazy is that we have space above and
below text content, and it's very difficult to line up the
text with other elements.
fantasai: You basically have to figure out how much space there is
and use a negative margin. This is not a very robust
system for achieving alignment.
fantasai: We need the ability to strip out the top part of the line
box that is above the text, so that you only have leading
between the lines but not above the first or below the
last line.
fantasai: But not only do we need to be able to strip out the
half-leading, which comes on top of the ascent, but also
space between the ascent and the visible glyphs, which
is some arbitrary number that the font author put in that
might not have much to do with anything.
fantasai: For different writing systems you want to use different
metrics here, e.g. cap height for English, ideographic
top for Japanese, etc.
fantasai: So we need to strip it down to one particular font metric.
<astearns> didn't we talk about a first-baseline-offset property at
some point in the past?
fantasai: The proposal is to add two new properties, for the over
and under edge.
fantasai: Which strips the size of the space down to a particular
font metric.
fantasai: The proposal is to have leading-trim-over/under properties
which strip out the space.
dbaron: I'm concerned about how this works if you have multiple
things in a line.
dbaron: If the goal is to have two things to line up with each
other, adding properties which help you remove one of the
things that cause the misalignment helps you get there, but
it is not solving the problem as directly as you'd like.
fantasai: We also need the ability to control the line box sizing
more precisely, but that's separate.
dbaron: What I'm thinking is that this seems more like a use case
for something like line grid, or something line grid-ish.
fantasai: It is not about having a grid.
fantasai: It is about having the top align with an adjacent thing,
or precisely controlling padding.
fantasai: If I have letters in a box with padding, the amount of
space between the top of the capital letters and the top
of the box, visually speaking, is not the number in my
padding property.
fantasai: Having a line grid will not make that go away. It makes
sure that consecutive lines have a particular rhythm, but
it doesn't strip out this space.
fantasai: The problem in the images in this issue is that the top of
the text is not lining up with the top edge of its
container.
<astearns> (agrees with fantasai fwiw - this seems useful with or
without a grid)
dauwhe: One of them is about getting two things to line up, and one
of them is about getting uniform spacing around something.
fantasai: The distance between the content box top edge and the text
as you see it visually is not controllable by the author.
dauwhe: I've seen this problem in my work.
fantasai: Our job is to make it so that you don't need JavaScript to
do basic layout.
fantasai: (Comparing to initial letter:) We do very precise
alignment for initial letter. It is not about measuring
the space, it is about getting the browser leave enough
space.
koji: Would like to have these metrics be accessible from both CSS
layout and from an API.
dbaron: What I was wondering is whether this is going to make other
things that we want to do in this space harder.
dbaron: Is this an independent thing that is going to be able to
float on its own or does it make other things more
complicated?
dbaron: It's probably ok but I'm a bit worried about it.
fantasai: If your concern is about the line grid stuff, this is just
about helping to set where that line grid starts.
fantasai: Line grid snaps baselines. Whatever calculation we do here
is not going to affect the ability to snap things to
baselines.
fantasai: And step sizing works on the margin box, so it's not going
to be badly affected by this either.
florian: Detail: This needs to apply to the first and last lines in
the paragraph, and not just to the direct children.
florian: This is not a problem with the design, but should be
explained.
florian: If you have several paragraphs, you want this to apply to
the first line of the first paragraph, not to each
paragraph.
dbaron: So you're saying it should be a non-inherited property that
applies to the first formatted line.
koji: I support it.
<jensimmons> if this is helpful to anyone, I just wrote this demo to
help me: https://codepen.io/jensimmons/pen/GYYpvN
RESOLVED: Add a leading trimming feature to the CSS inline spec.
Meeting closed.
Received on Sunday, 2 December 2018 11:26:44 UTC