- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:51:28 -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.
=========================================
CSS Box Alignment
-----------------
- RESOLVED: The static position rectangle is used as the alignment
rectangle of the statically positioned abspos (Issue
#1432)
- RESOLVED: For blocks the static position rectangle is the 0-height
rectangle between the start and end static position
offsets as defined in CSS2.1 (Issue #1432)
CSS Inline Layout
-----------------
- RESOLVED: initial-letter applies to inside markers + clarify spec
on :first-letter interaction with markers (Issue #2705)
- RESOLVED: Resolve as "won't fix" (no fixup) and add a note
explaining what dbaron already mentioned above [if you
set float then initial-letter won't apply] (Issue #688)
- RESOLVED: Approve the edit “All properties that apply to an inline
box also apply to an initial-letter (unless it is an
atomic inline, in which case the set of properties that
apply to an atomic inline apply) except for
vertical-align and its sub-properties, font-size, and
line-height.” (Issue #2700)
- RESOLVED: Accept sizing properties for initial-letter
[edit:
https://github.com/w3c/csswg-drafts/commit/4893b213ff17a4c8deab181c6997b47b93972911
]
(Issue #863)
- RESOLVED: The initial-letter will be the first inline that has
initial-letter not set to normal, (+details in the spec)
(Issue #2184)
- RESOLVED: The initial-letters will behave as if was taken/rendered
outside of its inline ancestors’s boxes (Issue #2184)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
CSS Box Alignment
=================
Scribe: emilio
align/justify-self on static position of abspos boxes
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1432
fantasai: We're asked to define precisely how the alignment
properties interact with static pos.
fantasai: The remaining one is how align/justify-self interact with
it
fantasai: The basic model for abspos and alignment is that you have
your abspos containing block and your offsets
fantasai: and that produces a rectangle in which you do your
alignment
fantasai: The default behavior comes from CSS21 and depends on
whether you're replaced or not
fantasai: That's an inconsistent mess but well defined
fantasai: Now the question is about what to do when offsets are auto
fantasai: For flexbox and grid children, the alignment container is
well defined: it's the flex or grid container’s padding box
fantasai: For the general case, we propose to make the alignment
rectangle the static position rectangle, that is, the
rectangle representing the position of the element if it
were not abspos
fantasai: In CSS2.1 you've got your CB, a bunch of content and your
element which would be abspos and then you calculate the
offsets that represent this rectangle.
[that is, both sides exist: static position is not a point]
fantasai: Depending on the 'direction' property, you ignore one of
the sides and then do your positioning calculations.
fantasai: Our proposal is defining the static position rectangle as
a 0-height rectangle occupying between the left and right
edges of the static position as defined in CSS2.1.
fantasai: Which means you can control the alignment of the abspos
element with respect of its static position containing
block
fantasai: Anyone has any comments?
iank: For orthogonal writing modes, your static pos rectangle may
change as soon as it's constrained
iank: If you've got a mismatch between the abspos CB and staticpos
CB as soon as you constrain it it's going to change the axis
you align it against right?
iank: So depending on the CB's writing mode that'll affect whether
you use align or justify self to get the centering
fantasai: No
fantasai: mismatch between writing-mode static pos and abspos CB
doesn't change which axis the alignment properties affect
Rossen: Bottom line is alignment happens in the CB
Rossen: Static pos is calculated in your parent and used in your CB,
and the wm that applies to it is the one of the CB
Rossen: I think there was one gotcha here which was if your static
position is affected by the wm of your parent
Rossen: Imagine you have two empty elements and an abspos inside
and the topmost is ltr and the inner one is rtl
Rossen: one abspos auto-positioned inside the inner one and the CB
is the outer one
fantasai: [draws]
fantasai: So you have an LTR rectangle. Inside that you have an RTL
box. Inside that you have the abspos
fantasai: [draws the static pos 0-height rectangle]
Rossen: So, if I position with `justify-self: start` for the
abspos...
fantasai: The direction used is the direction of the abspos CB
fantasai: If you want to use the abspos’s own writing mode you can
use `self-start`, but the axes you reference are the axes
of the abspos CB
RESOLVED: The static position rectangle is used as the alignment
rectangle of the statically positioned abspos
RESOLVED: For blocks the static position rectangle is the 0-height
rectangle between the start and end static position offsets
as defined in CSS21
Rossen: [actually resolves]
Rossen: Is that everything?
fantasai: Yes.
CSS Inline Layout: initial-letter
=================================
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jun/0020.html
<tantek> again what dauwhe referred to as "Tantek's indieweb thing"
http://tantek.com/2015/224/b1/alphabet-indieweb
<florian> thanks for the link
Should 'initial-letter' apply to 'list-style: inside' ::marker?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2705
fantasai: We're not expecting this to happen immediately, but we want
to make it apply since they should be laid out as any other
inline
fantasai: so proposal is 'yes, should apply'
eae: We're not opposed to it but it's not something we can implement
for a while, so as long as you're fine with that...
dbaron: It doesn't feel different to whether ::first-letter applies
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Aol%2C%20li%20%7B%20list-style-position%3A%20inside%20%7D%0Ali%3A%3Afirst-letter%20%7B%20color%3A%20green%3B%20background%3A%20yellow%20%7D%0A%0A%3C%2Fstyle%3E%0A%3Col%3E%0A%3Cli%3Ehello%0A%3Cli%3Etest%0A%3C%2Fol%3E
dbaron: I'm seeing interop in the non-desirable behavior so far
TabAtkins: We agree it should be the same, but our code for that is
bad
Rossen: In our case it already applies
fantasai: Really?
Rossen: Actually no
dbaron: So far Gecko / Chrome / Edge all seem to support
::first-letter but they support it on the thing after the
marker
<dbaron> ... and WebKit
myles: Why is putting it on the marker better?
fantasai: Cause it seems reasonable to style your markers / counters
using initial-letter
<fantasai> esp for numbered / lettered lists
TabAtkins: This is common on magazines, with list items being very
big and such
heycam: And if they go beyond nine?
TabAtkins: They don't, but if they do 'ok, there's ten, and it's
bigger'
[others]: That's two letters then
fantasai: We definitely allow multi-letter initial-letters
fantasai: What is a letter is a very interesting question outside of
latin
fantasai: We allow it to apply to the first inline box on a block
frremy: Is the marker position inline?
fantasai: Yes, only when list-style-position: inline
dbaron: It seems reasonable, but I'm concerned because we seem to
interop on :first-letter
fantasai: We don't really want to change how :first-letter works
fantasai: :first-letter should keep doing what it's doing
dbaron: Ok, I guess I'm fine with that
koji: When the list marker is a bullet and includes punctuation,
is the proposal to make initial-letter apply to the bullet
and the next letter?
fantasai: No, only for the first inline box, if it happens to be
a marker good, same for ::before, etc
xidorn: So if there's an inside marker, initial-letter doesn't
apply to anything afterwards, right?
fantasai: Right
Rossen: Ok, so we're on the same page, are we ready to resolve then?
Rossen: regardless of if/when it's implemented
myles: So if you have a list and the first letter of the list is
'This', how do you style it?
fantasai: Either an outside marker and initial/first-letter, or an
inside marker and first-letter
Rossen: [confirms ^]
florian: Not sure if I misunderstood
florian: But using initial-letter you cannot change the color of
the marker, you'd need to use `::marker` for that
<fantasai> thanks Florian!
Rossen: But in any case the first inline after the marker is targeted
by ::first-letter
everyone: Yes
myles: [confused]
dauwhe: Webkit will apply an initial-letter with li::first-letter,
which is troubling
[ fantasai tries to sort out confusion between what :first-letter
is (it's a pseudo-element) and what an initial-letter is (it's a
styling that can be applied to certain inline boxes, such as
the one selected by :first-letter ]
dbaron: So, to summarize: For list items, `::first-letter` ignores
the marker
dbaron: so the initial-letter property applies to `::first-letter`
pseudos and to inlines at the beginning of block
dbaron: so the spec doesn't have the exception for when
`::first-letter` is not at the beginning of the block due
to an inside marker
dbaron: and we need to clarify that `initial-letter` doesn't apply
in that case
dbaron: Maybe bidi can introduce a similar problem
fantasai: We need to clarify that, but the spec already mentions bidi
<fantasai> “If initial-letter is applied to an inline-level box that
is not positioned at the start of the line due to bidi
reordering or which is otherwise preceded by other
inline-level content, its used value is normal, and it is
not formatted as an initial-letter.”
dbaron: So, the other piece is that the bit about initial-letter can
apply to an inline at the beginning of the block, but we need
to clarify that it includes the inside marker
florian: The piece fantasai quoted needs to also clarify that it also
applies to `::first-letter`.
Rossen: Ok, now that we're on the same page, is there anything else?
tantek: So the example that dauwhe mentions, it is an ordered list,
so I was trying to make it work with the markers with
<ol type=a>, but I could make that to work cross-browser at
all, so if anyone is trying to define those interactions you
should experiment with that today
tantek: I had to use with `list-style: none`
fantasai: There's only one `initial-letter` impl so far and it's
pretty buggy
dauwhe: That's an understatement, but I'm still glad it's there
Rossen: fantasai, so should we resolve then?
Rossen: Any objections?
RESOLVED: initial-letter applies to inside markers + clarify spec
on :first-letter interaction with markers
initial-letter vs float
=======================
github: https://github.com/w3c/csswg-drafts/issues/688
fantasai: So there's an issue of the interaction between `float` and
`initial-letter`
fantasai: `float` blockifies an element, and `initial-letter` applies
to inline boxes only, so per spec right now, there's no
interaction: you get a floated block.
fantasai: It was pointed out that you may want to use float as a
fallback for initial-letter
fantasai: so we may want to ignore `float` if `initial-letter` is
specified as well
dbaron: florian: We should make initial-letter override float
heycam: You could use @supports
tantek: That's not enough because when you're actually trying to make
it work you tweak other properties like font-size but also
line-height
fantasai: font-size and line-height are ignored already
tantek: You also need margin
fantasai: That's not ignored
dauwhe: Yeah, tantek is right
<tantek> from view-source:http://tantek.com/2015/224/b1/alphabet-indieweb
<tantek> .h-entry li::first-letter
{ float:left; margin:0.04em 1px 0 0; font-size:5.5em;
text-transform:uppercase; line-height:0.8; }
florian: So margin is not covered but I think the compromise is
reasonable if you're not trying to do pixel-perfect drop-cap
both with and without first-letter
florian: You'd just not do the margin
Rossen: Let's get back to the issue at hand
Rossen: So tantek, you are against overriding float? or just saying
that there's a bunch more?
tantek: Not a lot, but just a few properties beyond float
florian: So for two of the three properties you want to cover it's
fine already, for the rest you have @supports
florian: because the margin hack you may do I think it's still useful
for initial-letter to override floats
tantek: I don't think you can make the initial-letter look good
without margin
fantasai: So you're arguing we shouldn't make the change?
fantasai: [re-states the proposal]
fantasai: The current state is that computed value rules for
'display' cause a element with 'display: inline' with
'float' not 'none' to turn into 'display: block'.
fantasai: The proposal afaict is that if 'initial-letter' and 'float'
are set on a 'display: inline' element, it won't compute
its 'display' to 'block'. Thus 'initial-letter' would apply
and 'float' wouldn't.
emilio: So you'd make an inline with `float: !none`?
emilio: We want initial-letter to turn float to none, instead.
Scribe: frremy
emilio: Can we determine if initial-letter applies based on the box
type only?
emilio: I think we should make the rule as dumb as possible
emilio: Even if this is a block, initial-letter turns off float
TabAtkins: I agree, we should recommend authors use @supports
tantek: A simpler rule would also make it clear to authors they
should use @supports
TabAtkins: We could add a note to the spec
dbaron: And it's also very likely people will not use initial-letters
on things where it should not apply
Rossen: I believe this (?) should be the same rule
dbaron: I advocated for fixup before
dbaron: I am fine with no fixup in place
dbaron: but then I argue for a note that says that if you set float,
then initial-letter won't apply
tantek: Simple fixup that forces float to none helps authors to debug
using devtools
emilio: Even now the display fixup order is not fully interoperable
emilio: so I'd prefer no fixup to not muddle fix further
Rossen: No fixup is better for implementers, I agree
* tantek would also slightly prefer no fix-up, can live with simple
fix-up that is reflected in the value for the property shown
in devtools so that it is more easily debugged by authors
dauwhe: I don't have a strong opinion, but it would be nice to have
an example in the spec to make things clear
Rossen: The only good reasoning for fixup was be compatible with
existing code, but now we have @supports so authors should
just that
Rossen: So, any objection to resolve as "won't fix" for now and
add a note explaining what dbaron already mentioned above?
RESOLVED: Resolve as "won't fix" (no fixup) and add a note explaining
what dbaron already mentioned above
tantek: Note?
astearns: Yes, because the confusion dbaron was worried about was
for implementers
dbaron: Yes, note is fine
Properties that apply to initial-letter
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2700
<fantasai> See
https://drafts.csswg.org/css-inline-3/#initial-letter-properties
<fantasai> “All properties that apply to an inline box also apply
to an initial-letter (unless it is an atomic inline,
in which case the set of properties that apply to an
atomic inline apply) except for vertical-align and its
sub-properties, font-size, and line-height.”
<fantasai> for reference, the old section:
https://www.w3.org/TR/2016/WD-css-inline-3-20160524/#initial-letter-properties
fantasai: Before was a whitelist, current spec text is more general
fantasai: All inline props except vertical-align, font-size and
line-height
dbaron: So this includes margin/padding/border?
fantasai: Yes
dauwhe: Yes
florian: So we are just resolving to approve the edit?
fantasai: Yes
<tantek> is outline in that list?
TabAtkins: Our only objection is that this is one more list to
maintain
TabAtkins: and we already keep forgetting to do this for first-letter
and first-line
TabAtkins: Problem happens whether you blacklist or whitelist
TabAtkins: but the failure mode and the fixed mode of starting from
an allow list is better
fantasai: We came to the opposite conclusion because most things
should apply
fantasai: We don't expect many new exceptions
fantasai: but we expect most properties that apply to inlines to be
useful
dauwhe: The blacklist is useful because it is short and enables to
grasp the scope of the feature
florian: Would like a note that explains the principle, so that new
properties would be able to be categorized by this rule even
if we forget to add them
fantasai: But they wouldn't be able to apply because the algorithms
don't take them in consideration
florian: That was just a proposal, but I'm fine as-is
Rossen: So, can we resolve on the blacklist with three properties
then?
TabAtkins: No objection
dbaron: Sizing properties apply too?
fantasai: This is the next issue
dbaron: Ok
RESOLVED: Approve the edit
<dbaron> :first-letter is at least 22 years old:
https://www.w3.org/TR/WD-css1-960220.html
applying width/height to initial-letter
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/863
<fantasai> https://github.com/w3c/csswg-drafts/commit/4893b213ff17a4c8deab181c6997b47b93972911
fantasai: Request from tantek
fantasai: seemed reasonable
fantasai: We would like the group to review the proposal
<fantasai> https://drafts.csswg.org/css-inline-3/#initial-letter-model
2nd bullet
dbaron: In case of alignment, what gets aligned into what?
TabAtkins: The letter aligned inside the box
dbaron: The alignment properties are not specified to apply?
fantasai: Well, we use them in the algo, we just forgot to mention it
fantasai: We can fix this
dbaron: Why is that useful?
TabAtkins: It's super useful for width
dbaron: Seems true, but for height this is more concerning
dbaron: because now you have to align with the lines and take the
height into consideration
<dauwhe> using width and text-align with initial-letter
https://usercontent.irccloud-cdn.com/file/G7EqH0Jd/tantek.png
fantasai: You create a box around the glyph
fantasai: From there, they are locked, and there are two ways to
align this box
fantasai: The exclusion however always use the glyph bounding box
dbaron: Globally, this seems reasonable
dbaron: It's more complex than the last time I looked, but this still
looks fine
fantasai: There was already an similar feature before
fantasai: (explains why you needed to do this in the past)
koji: Two days ago, we said the exclusion space is created only for
the second line
koji: so if you say margin-top: 30px, how does that work?
fantasai: It pushes the entire block, including the initial-letter
fantasai: The first line is positioned with the glyph
fantasai: Details for how that would work is another issue, which we
will address later, let's not discuss this now
fantasai: but since the initial-letter and the first line are locked,
the initial-letter will never sunk further than the first
line
<dauwhe> some discussion:
https://drafts.csswg.org/css-inline/#raised-sunken-caps
Rossen: So unlike other inline, the initial-letter's margin has an
effect on layout
koji: Does that margin collapse?
fantasai: waaaiiiiiiiiiiiiiiiiiiiiiiiit :)
fantasai: Let's not discuss this today
fantasai: Let's push this to TPAC
Rossen: Ok, so were are we towards getting a resolution
fantasai: Review and accept the edit allowing width/height/alignment
dauwhe: And we do have good use cases for this stuff
Rossen: Any objection?
(no objection)
RESOLVED: Accept sizing properties for initial-letter
box tree nesting vs initial-letter
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2184#issuecomment-391832514
fantasai: We didn't define very clearly what we defined as
"the first inline"
fantasai: so, it's slightly weird, because adding spans should
not change result most of the times
fantasai: but in this specific case, if they are nested, it's
not clear which one to take
<dauwhe> https://github.com/w3c/csswg-drafts/commit/412bfeabf53c980babe9845c3a2684904790c2e2
fantasai: (looking at notes and issues)
<fantasai> “Specifically, initial-letter also applies to any
inline-level box that is the first child of its
parent box and whose ancestors (if any) that are
descendants of its containing block are all
first-child inline boxes that have a computed
initial-letter value of normal.”
fantasai: (reads pasted in text)
florian: If you have multiple spans, the outer one does have
a border, but the nested one has initial-letter
florian: does the border wraps around the "nested" initial-letter?
Rossen: I would assume not
florian: So it becomes out of flow, kinda?
Rossen: Yes
florian: There are two options (1) you take the nested span out
of flow (2) or we can refuse to initial-letter any
nested span inside something that has a margin, border,
or padding
Rossen: The second options is though from the styling point of view
florian: ok, then let's do 1
PROPOSED: The initial-letter will be the first inline that has
initial-letter not set to normal, (+details in the spec)
Rossen: Any objection?
RESOLVED: The initial-letter will be the first inline that has
initial-letter not set to normal, (+details in the spec)
<dauwhe> see https://github.com/w3c/csswg-drafts/issues/743
PROPOSED: initial-letter will behave as if was taken outside of
its inline ancestors
PROPOSED: The initial-letters will behave as if was taken/rendered
outside of its inline ancestors
RESOLVED: The initial-letters will behave as if was taken/rendered
outside of its inline ancestors
Received on Tuesday, 24 July 2018 23:52:24 UTC