- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 26 May 2017 20:40:48 -0400
- To: "www-style@w3.org" <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.
=========================================
Writing Modes
-------------
- There was conversation as to if the spec was passing enough
tests to move to REC. In general it seemed as though failures
were implementation problems or problems with related specs,
not problems with the Writing Modes spec.
- RESOLVED: Change "containing block" to "parent box", and define
that.
- RESOLVED: Republish WM as CR, after making the normative change
for the current open issue.
- There will be a four week review period after the CR publication.
CSSOM
-----
- RESOLVED: CSSOM can use either USVString or DOMString
- If any web compat issues are found from this change, issues
should be raised.
CSS Box Alignment
-----------------
- Discussed proposal to use final scroll position to find last
baseline of scrollable boxes vs current resolution of using
the higher of the last baseline and bottom margin edge at
initial scroll position.
- RESOLVED: Change bottom margin edge to bottom border edge.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Scribe: TabAtkins
Writing Modes
=============
Implementation report
----------------------
koji: The current status of Writing Modes is that we have an impl
report.
koji: In the topic.
koji: And a DoC update.
koji: One open issue from Boris.
<koji> https://wiki.csswg.org/planning/tokyo-2017#topics
koji: If there are any comments on the impl report or DoC...
koji: Hopefully solve the last open issue, and get the resolution
to publish.
koji: If anyone has feedback, please let me know.
Florian: I have on both.
Florian: Some detailed feedback, but first...
Florian: I think we should indeed go to PR with this module; it's
in a good shape.
Florian: The impls are coming along, and there are political
reasons to take a stand and say this has made progress.
Florian: But we should do it with the understanding that we are
stretching a little the definition of what a REC is.
Florian: Our charter says "2 indep.. impls of each feature", and
that's fuzzy - what's a feature?
Florian: We don't need 2 impls of the entire spec as a block; I
think we have two impls of each testable statement.
ChrisL: That's correct.
<tantek> at least a property is a feature, or a value
fantasai: For example, WM in table cells. Impls do slightly
different things.
fantasai: It's a fairly significant use-case for vertical text,
but it flat-out doesn't work.
Florian: So it rotating a table cell is a feature, we have it, but
we don't have sizing in the same browser.
<Florian> http://jsbin.com/vubeti/edit?html,css,output
fantasai: So it's more of a weird way the test got split out.
Florian: Haven't tried this test-case in the latest everything,
but recently, not a single browser does everything.
Florian: Enough browsers pass each aspect that we can pass all the
tests, but none pass it meaningfully.
Rossen: What do you think should do?
Florian: [details that I missed]
Florian: With that said, I think we should still go to PR.
Florian: This is a large enough spec with fingers everywhere;
we'll find issues for years. If we wait for it being 100%
complete, we'll never go to REC.
Florian: Just want to make it clear that just having unit tests
passing doesn't mean the job is done.
koji: As far as I understand.
koji: ...w3c process means you have to pass unit tests
TabAtkins: Passing all unit tests isn't enough to say you
implement the feature, you do need integration tests
<TabAtkins> (If you can pass all the tests but not implement the
feature correctly, there aren't enough tests.)
Rossen: That's fine. People will find bugs, they'll file, we'll
become more interoperable...
iank: We'll be doing a revamp of our table code probably 9-12
months from now.
iank: Expect we'll have more feedback at that time.
Florian: To be clear, I didn't take tables as the sole thing; it's
representative, and I was putting together a talk for the
AC.
Florian: I was doing some example coding and saw we didn't have
interop.
dbaron: I'm worried about how this interacts with intrinsic sizes.
Much is not in WM, some is in Sizing, some I think is not
defined.
dbaron: I think when you say something "doesn't work", it's
because it doesn't do what you expect, but the obvious way
you can fix the spec might not be something we're willing
to do.
dbaron: So it might take changes to the spec to get to the point
where we agree on an intrinsic sizing behavior. Maybe
substantial.
dbaron: So this makes me worried to take this to PR right now.
Florian: Agree. I still think PR is useful for political reasons.
iank: Intrinsic sizing isn't well-defined for WM, right?
fantasai: It is, I think.
dbaron: I disagree.
fantasai: It requires doing layout.
dbaron: Which I don't ever want to do.
fantasai: ...which Firefox and Chrome don't have the architecture
for, yes. But Edge does, IIRC.
Florian: For this spec, we'll find issues for a very long time.
I'm not sure it would be a good move politically to delay
the spec for 5-10 years.
fantasai: Solving vertical text in table cells requires doing
intrinsic sizing after layout, and I don't think it's
reasonable to say that we will never solve what is a
major use case of vertical text
dbaron: I don't think that it requires not addressing those use
cases.
<tantek> This sounds to me like 1) we don't have actual interop
(use cases), 2) if we don't know what features are
features, we are underspecified CR exit criteria, and
need to fix that with a new CR that specifies it, 3) if
we have disagreement among browsers on how these features
work right now, it is likely we will need normative
changes to fix it, which means we need a new CR
<tantek> "will find problems a very long time" is just normal
maintenance expectations and must not be used as an
excuse for any decision.
Florian: HTML has gone with some holes and vagueness.
Florian: We have a fairly comprehensive test suite.
TabAtkins: Mentioning HTML in this regard isn't meaningful.
Florian: There's been substantial push from Japanese gov to get
this to a more stable level.
Florian: As a milestone.
Florian: Maybe we wouldn't ideally want to call it Rec, but that's
the name we have; we can still have things to fix.
koji: Ignoring the Japanese community, Rec always to me means
there can still be work to do.
tantek: That's false. "There's always maintenance" is true for
everything. But it's a difference of degrees - there's a
difference between holes and interop.
fantasai: There's always going to be interop issues - CSS2.1 still
does. There's a just different thresholds you can hit.
fantasai: It's always a judgment call, and a reflection of the
issues we have going in.
fantasai: I think there's still some issues to edit in, but
there's not much issues coming in for the spec itself,
just minor details.
fantasai: There are a lot of impl bugs - this spec affects *every*
layout system - and there will be forever.
tantek: You're using incoming issues as a metric - Florian, did
you file issues for these?
Florian: No, because they're not spec bugs as far as I can see. I
could be wrong.
tantek: If you can't make a judgment call, file an issue.
tantek: So someone else can decide.
fantasai: A large part of the complexity of the spec is its
interaction with all of CSS 2.1.
fantasai: There's no error in how the interaction is described,
there's just a lot of details that can get wrong in
implementations.
tantek: A particular issue that bothered me - behavior in table
cells.
tantek: In CSS 2.1, how properties worked in/out of table cells
was one of our biggest sources of interop problems.
tantek: So if we can't even do that, we have major problems.
Florian: I don't know if it's a spec problem - my reading isn't
showing a problem - but are impls wrong because they
don't know it's wrong, or they know it but can't fix it?
rbyers: That's what tests are for.
Florian: I don't have budget for detailed investigation work. I'm
just raising the flag.
Florian: So being aware of that, do we do that and go to Rec in a
year or five, or go to Rec for political reasons and
still fix it.
dbaron: A third possibility is that the impls *are* doing what's
specified... there's plenty of holes.
fantasai: There's bits where things are defined "analogously to
2.1" - if you don't make that translation correctly, you
get some bugs.
fantasai: That's where most of our issues come from - people not
applying the analogy fully and correctly.
fantasai: Different from Flexbox or the like, where interop issues
are a problem directly in the spec.
tantek: I see that; we had similar with box-sizing, and we had to
go into more detail. Maybe that's the solution.
fantasai: That means rewriting the 2.1 block/inline layout specs,
which isn't happening right now.
tantek: Sure. But currently our features just don't pass the
interop guidelines.
Rossen: I don't believe this is true. I agree with fantasai that
WM is a horizontal feature that cross-cuts, like intrinsic
sizes.
<tantek> Fundamental problem is: do use-cases have interop or not?
fantasai: Like logical properties; we don't define each individual
property, we just describe the mapping and the names.
Rossen: Counter-example to get away form WM for a second - when we
started defining fragmentation, another horizontal
feature, we had a choice - start defining how
fragmentation works for everything, and put all of this
into one single spec, or define the basic rules and what
it is and how it's supposed to be applied, then every
other layout module defines how it happens.
Rossen: WM is not that different.
Rossen: Going thru the WM spec, the WM part is pretty well-defined.
Rossen: There are interactions with every layout module, there
will be integration issues - a flexbox inside a table
inside a grid, all with different WMs, there will be
issues that impls have to work thru, and we do.
Rossen: That's not a WM problem, that's an integration problem.
Rossen: So for horizontal features, I don't want us to have to
pull all of CSS into the feature and blaming all the buggy
integrations on this particular spec.
tantek: I get that, but a bit of a strawman - inside a table cell
or not, or inside an abspos or not. Those seem simple
circumstances, that an author would expect to work.
tantek: If we don't have tests that demonstrate interop on that, I
find it hard to believe we have interop.
koji: We have those tests, but only some are passed in each
browsers.
Florian: Worse, each layout mode not only has to work in other
WMs, it has to work in orthogonal flows.
Florian: We have only 1k tests - it can't cover everything.
Florian: But if we cover everything that exists today, we'll never
finish.
tantek: Still strawman. If the simple examples you came up with,
just to show something at the AC meeting, that's stuff we
should look into.
tantek: You're not making a newspaper, just simple examples. If
you don't have interop there, something's broken.
tantek: Maybe spec, maybe impls, but we have to investigate.
tantek: I'm not asking for perfection.
<Florian> http://jsbin.com/vubeti/edit?html,css,output
koji: So what do you say when two impls pass?
TabAtkins: He's saying that we have a theoretical integration test
failing, even though unit tests pass.
tantek: Not even a complicated one - no deep nesting - just simple
"in a table cell".
Rossen: So there are impls that are behind, and it's up to them to
catch up.
koji: Blink and Webkit don't implement it in table cells, but we
plan to implement it
Florian: And the two that have it, MS and Mozilla, behave
differently, and neither is good.
Florian: Mozilla doesn't implement sizing - your table cell will
be rotated but sized wrong.
Rossen: So it's an impl problem, file a bug.
Florian: Unless Mozilla won't fix it - then it's a spec problem.
fantasai: Koji said that Chrome/Blink will fix it though
rbyers: Sounds like we should have a more integration-y test.
Rossen: So currently 98% passes in two impls.
Rossen: Which means it works in a lot of major cases.
Rossen: I can find you float bugs today, and we've had floats for
15 years.
Rossen: It would be a little unfair to blow it up and say 2.1
can't go to Rec.
Rossen: At the same time, there's plenty of content that's
depending on vertical WM that works well.
Rossen: epub, etc.
Rossen: Even though it's not as interoperable as it should be.
Rossen: But WM today, for 90% of use-cases, is usable as-is.
Rossen: It would be a little unfair to over-index on one thing and
let it skew whether we go to Rec.
tantek: I'd call into question your 90% assertion.
tantek: If every example Florian tried to show is failing
interop...
Florian: I haven't tried comprehensive testing, so maybe I was
just very unlucky to run right into the problems.
koji: And table cells are a known issue for two browsers, so you'd
have to pass both for the two remaining.
koji: Pages have really changed today in using WM. Nowadays, many
pages are using WM in real pages, I see this supporting
Rossen's idea.
astearns: And jensimmons started writing up tons of WM examples a
few months ago, and she's not been reporting spec bugs.
Florian: So the devil is in the details here. It's def not done
and tied up, there are problems, but they're probably not
that bad - it's used in the wild - and probably not that
good - we find some problems.
<jensimmons> I haven’t found bugs in Writing Mode implementations,
no. And yes, I always test cross browser (although
sadly, not Edge so much since that’s on a different
machine). My biggest complaint about WM
implementations is that only Firefox has
writing-mode: sideways-*;
tantek: Are people testing in one browser?
rbyers: 1 in 200 pageviews in Chrome are using WM. We rarely see
features that popular for Chrome-specific code.
koji: And people end up knowing that WM doesn't work on table
cells; they instead put a <span> in there as a workaround.
<tantek> good to know koji, thank you
<Rossen> here's what we see in terms of usage
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/writing-mode/
<rbyers> And here's Chrome usage: https://www.chromestatus.com/metrics/css/timeline/popularity/394
* jensimmons expects Writing Mode usage to increase now that CSS
Grid has shipped. Trying to use WM without Grid was
not nearly as exciting. A lot of ideas for WM require
Grid.
Rossen: Koji, you had some questions/issues to go over, can we get
back to that?
Florian: I have some comments, but they don't matter if we decide
to go ahead with publishing.
Florian: There's some places in your report that lists tests that
fail, but it's okay because they're cross-spec tests for
specs not in Rec, but for some I can find what the other
spec is.
fantasai: Some are the unicode specs; if you have bad unicode
data, some of these will fail.
Florian: But isn't Unicode REC-equivalent?
fantasai: Yeah. But if you just miss some cases in scripts, it's
more of a Unicode bug than a WM bug.
Florian: So do we want to go that level of detail, or do we just
say "eh, we're going to Rec, don't bother".
astearns: The # is so small, that removing them doesn't change the
% passing (at integer courseness).
Florian: I think we shouldn't mislead ourselves that this is
Done©, but as long as we're aware of that, I think we can
move.
<skk> For my understanding, WM is huge spec, and it affects lots
of other specs. And it looks difficult to satisfy
interoperability with other specs. As Florian said, "being
aware" might be important. So, WM L4 or L3.1 (it doesn't
exist now. This might be bug-fix spec for WM L3) is needed
for "being aware".
Orthogonal flows on inlines and display transformation
------------------------------------------------------
<fantasai> https://github.com/w3c/csswg-drafts/issues/1212
koji: Can we discuss bz's issue?
koji: When WM is different from parents, the spec says it
blockifies.
koji: bz is saying that "blockifies" can't compute containing
block before layout.
koji: It says "parent element", should be "parent box", but parent
box isn't well-defined.
dbaron: Historically containing block depends on styles, but this
is trying to make styles depend on containing block.
fantasai: We can change it to parent box, that's defined in
Display.
fantasai: Only important case is when display is inline.
fantasai: If any parent of an inline, which is also an inline, has
a different WM, it will have become an inline-block,
which makes it the containing block.
fantasai: An inline can't have a different WM from its containing
block anyway, it becomes an inline-block.
fantasai: The difference between parent box and parent element is
only really relevant for display:contents afaict.
fantasai: You look "past" a display:contents.
fantasai: There are other cases where this clause doesn't apply
anyway..
fantasai: I'm in the process of trying to figure out the wording
with bz, but I think we can just change to "parent box"
as long as people are okay with walking up
display:contents.
dbaron: You can come up with a new term that is "parent element,
walking thru display:contents".
fantasai: That's just "parent box", no?
dbaron: Box tree isn't defined yet.
[fantasai and tabatkins bicker over whether it's sufficiently
defined]
koji: [provides some example that I missed]
fantasai: I think I can fix this over lunch.
Florian: So we're looking for "parent element, but walk up
display:contents".
koji: So should we define this in WM?
fantasai: It's in Display; if it doesn't quite exist yet, I'll
define it.
Florian: So it sounds like we agree on behavior, if not on
terminology. Can we resolve to that?
Rossen: Sounds like nothing to change in WM?
fantasai: There's a mention of "containing block" that needs to
change to the new thing.
koji: So proposal is to change "containing block" to "parent box",
and define that.
Florian: And we can define "parent box" without needing the whole
box tree.
TabAtkins: "Closest ancestor element that generates a principle
box."
RESOLVED: Change "containing block" to "parent box", and define
that.
<tantek> that's a normative change right?
Publication
-----------
koji: So with the last open issue resolved, I wonder from the last
discussion if we're fine to resolve to publish or what.
tantek: Didn't we just make a normative change?
astearns: We need to make the update, get bz's approval, *then* we
can ask for PR.
Florian: Do we have to cycle CRs since it's a normative change?
tantek: Technically, yes.
tantek: Any excess features to drop?
fantasai: We already did.
Rossen: So we can resolve to republish CR with that change?
RESOLVED: Republish WM as CR, after making the normative change
for the current open issue.
Rossen: Response period?
Florian: 4 weeks, shortest time, we're not looking for any
particular input here.
<fantasai> just bzbarsky's input :)
CSSOM: USVString vs DOMString
=============================
Scribe: fantasai
<dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/1217
SimonSapin: In JS, strings are made of a sequence of 16-bit
integers
SimonSapin: Can be any arbitrary sequence
SimonSapin: Usually interpreted as UTF-16
SimonSapin: But doesn't have to be well-formed UTF-16.
SimonSapin: In particular, there's a range of values that are called
surrogates.
SimonSapin: If you have a leading surrogate plus a trailing
surrogate, i.e. 2 UTF-16 ints, that forms a single
Unicode codepoint.
SimonSapin: But in JS, nothing stops surrogates from appearing in
the wrong order, or a single one by itself.
SimonSapin: This is invalid Unicode.
SimonSapin: But you can do it in JS.
SimonSapin: If you want to convert that string to UTF-8, UTF-8 is
designed to exclude surrogate codepoints to align with
set of valid UTF-16 strings.
SimonSapin: So not all JS strings can be represented in UTF-8
without losing data or using an escaping mechanism.
SimonSapin: Wasn't an issue, because every browser internally uses
same type of string as JS7.
SimonSapin: So if you have CSSOM string that has an unpaired
surrogate, e.g. in an ident or content property string
SimonSapin: it's ok.
SimonSapin: What's changing now is that in Firefox, we have a
project called Stylo, which is to import Servo style
system into Gecko.
SimonSapin: That style system is using Rust str type for all
strings
SimonSapin: which is based on UTF-8, so it cannot represent
unpaired surrogates.
SimonSapin: What that means is in practice, whenever a string
comes from CSSOM and goes into the style system in
Servo and in the future in Firefox, we convert to
UTF-8 and in that process, any unpaired surrogate is
replaced with U+FFFD REPLACEMENT CHARACTER
SimonSapin: So there is some data loss.
SimonSapin: However, I think this kind of situation only happens
accidentally.
SimonSapin: Fact that JS strings are this way is not a feature,
it's a historical accident.
SimonSapin: I don't think there is a real compat risk with
shipping Firefox this way.
SimonSapin: Still, it's a deviation from current interoperable
behavior, so wanted to bring it up.
Florian: Proposal?
SimonSapin: In WebIDL which we use to define interfaces for JS,
there is two string types. DOMString corresponds to JS
strings with arbitrary 16-bit.
SimonSapin: Then there is USVString, Unicode Scalar Value String,
which has no unpaired surrogates, only well-formed
unicode
SimonSapin: When you convert DOMString to that, you get the same
behavior as in Servo, replacing lone surrogates with
UFFFD.
SimonSapin: If we want to keep this interoperable, then I propose
to use USVString for all of CSSOM.
ChrisL: Seems like a good idea, since unpaired surrogates are only
an error.
ChrisL: Only used for binary data, and can't imagine that in CSSOM.
TabAtkins: USVString is supposed to be avoided in WebIDL.
TabAtkins: Currently only used in networking protocols that use
scalar values.
TabAtkins: Requires extra processing compared to UTF-16 strings.
ChrisL: Maybe in custom properties though, people would want to
store binary data; they should encode it to avoid syntax
issues though so no big deal.
dbaron: Annevk disagrees with advice in WebIDl spec, btw.
dbaron: There's a github issue against WebIDL spec to give
coherent advice, but ppl disagree on what that should be.
dino: Appreciate that you want to use rust string type, but we all
have to use our own string types.
dino: Maybe resolution is all DOM strings should be that way.
TabAtkins: No, that would break a lot of things.
TabAtkins: People smuggle binary data in JS strings
TabAtkins: But for things that talk text, could do it.
dino: Everything, not just CSSOM.
Florian: Would it be reasonable for implementations that don't do
rust strings internally?
myles: If we don't know perf impact, can't agree to do this
myles: So somebody somewhere has to try it first before we agree
to it.
SimonSapin: Tab, did you mean changing JS or DOM would break things?
TabAtkins: Some DOM Apis have to be 16-bit, e.g. Fetch ...
rbyers: It's not in Chrome.
[TabAtkins muses]
till: It's not entirely out of the question that it would be
Web-compatible enough that we could change it in JS itself.
fantasai: For JS itself, Tab was saying it's not doable, but for
DOM Apis more likely to be possible.
<TabAtkins> Mistook the API - *Fetch* uses USVString, but XHR uses
DOMString
iank: Need to check with architecture folks about this
iank: Our architecture folks in charge of bindings and string
types and stuff.
iank: Looked for code where we switch to USVStrings, and that's
very expensive for us it looks like.
iank: Might be perf problems.
fantasai: My take is that this is a very weird edge case with no
real use: lone surrogates in the CSSOM.
fantasai: So I would say, let's spec you can use either, and we
don't care.
myles: Every string would have to get transcoded, that's crazy.
TabAtkins: ....
iank: Would have to guarantee that that block internally is clean.
TabAtkins: Move to UTF-8 clean internally.
iank: Sounds non-trivial.
Florian: Spec that either is Okay then it's not any work.
Florian: If we can't spec that, then it means web depends on it,
so Servo will have to bite the bullet.
TabAtkins: I'm okay with doing that, put a note that we'd like to
move to USVString.
shane: If there's a web compat problem, then it's a problem.
TabAtkins: That means someone is injecting lone surrogates into
the CSSOM. Can't come out of the parser.
TabAtkins: In that case probably buggy anyway.
shane: If ppl notice a problem, they'll file bugs.
eae: It's very hard to get into the situation except intentionally.
myles: Does Servo have to translate between JS string and UTF-8
String all the time?
SimonSapin: Yes
SimonSapin: We have optimizations, e.g. if ascii then stored in
one byte per unit, skip UTF-8 conversion.
Florian: Can we just resolve on allowing both and if it's a problem,
if it comes back with issues, we'll change the spec?
fantasai: I think interop in this very very weird case is not
worth any effort, so spec should allow both.
till: It's not servo-specific, others might want UTF-8 codepaths.
myles: I believe that you believe that.
Rossen: Any objections?
rbyers: We should re-discuss if we find web compat issues.
RESOLVED: CSSOM can use either USVString or DOMString
fantasai: We can always raise issues if they're found later.
SimonSapin: This also affects other specs with WebIDL interfaces,
e.g. CSS Fonts defines @font-face interfaces
Florian: Should we define a CSSString?
...
iank: But if we do this later...
fantasai: We are literally deciding that you can do either,
forever. Unless someone comes back and says "lone
surrogates in CSSOM are an important use case and I need
them"
* fantasai is sure that will never happen
[Rossen discusses agenda items]
CSS Box Alignment: Last baseline alignment of scrollable boxes
==============================================================
Scribe: shane
<dbaron> Github topic: https://github.com/w3c/csswg-drafts/issues/766
fantasai: If you have a scrollable box with content
fantasai: question of last baseline, once content is taller than box.
fantasai: Most recent resolution was that if last baseline is
above the fold then use that, if below the fold then
floor at bottom margin edge
fantasai: previously just used bottom margin edge regardless.
fantasai: TabAtkins and I want to suggest that once scrolling
offscreen, scroll whole box to the bottom and pick last
baseline at final scroll position.
myles: In order to know where baseline is then you need to do a
scroll, look at baseline, unscroll?
fantasai: Just need to figure out bottom scroll position then find
last baseline's position then subtract bottom scroll
position from it.
dbaron: What if there's a bunch of whitespace and when you scroll
to the bottom your last baseline is way up?
smfr: Does this apply to overflow: hidden as well as overflow:
scroll?
smfr: An alternative is to align to the baseline of the last
visible line (i.e. the one you can see).
dbaron: That's weird because different font metrics could make it
pop differently.
smfr: Won't you get popping with this too?
iank: Can we just consider this an edge case?
Florian: What's the use case?
Rossen: DIY form controls.
iank: If you've got a eula at the bottom of a form, e.g.
Rossen: In the non-overflowing case it makes sense to align to the
bottom line, I think we all agree to that much.
dbaron: I agree it's abstractly sensible. But we have interop on
the opposite right now.
fantasai: WebKit implements the resolved behavior and has for many
years. So no interop.
Rossen: Which means nobody cares?
tantek: So we have interop except for WebKit.
fantasai: Yes, WebKit's behavior is higher quality than the
specced behavior.
Florian: And this means there isn't evidence that there's
dependence on either behavior.
myles: So are there other use cases than a select box?
flackr: Proposed behavior is has discontinuity - if baseline falls
below margin then it might suddenly jump upward.
fantasai: No.
Rossen: Do you have the problem of baselines above box today?
myles: We just take the ???
dbaron: People often put a page of blank space below scrollable
areas.
<smfr> https://codepen.io/anon/pen/Wjreqe
myles: ???
Rossen: Which is less than optimal for when there's no overflow.
myles: Resolution was 3 years ago, hasn't been any movement so far.
fantasai: It is in CSS Box alignment module which is about to hit
CR.
Rossen: When you changed this were there use case motivations?
myles: From what I remember it wasn't use case based. I was
working on some site compatibility problem
myles: something like a row of icons and we were shifting them
vertically.
Rossen: Which was dbaron's concern - that we might start breaking
such content.
Rossen: I share that.
iank: Reiterating: currently 3 impls just do the end margin edge.
Current resolution is to do last baseline if no overflow,
otherwise end margin edge.
myles: Logic was that if text shorter than block, putting
overflow: hidden on should have no effect.
iank: That's different to no overflow though, right?
myles: nope, *draws*
iank: But if you have a massive box with no text and it triggers
overflow, then last baseline would go to end margin edge?
smfr: I posted a codepen with examples: (https://codepen.io/anon/pen/Wjreqe)
fantasai: That's not clear.
fantasai: If the last baseline is above the bottom edge and
there's no overflow, why would you jump if there was
overflow?
fantasai: Baseline should be the bottom edge only if it would
otherwise be below.
myles: That describes what we currently do.
iank: OK so if there's overflow you still look at the last
baseline of the text.
fantasai: Seems weird we're clamping to the margin edge rather
than something where the text stops being visible like
border box.
Rossen: OK so back to myles' comment, is anyone actually going to
change this?
smfr: I can't see any difference between browsers in this codepen.
I think I've captured the behavior.
smfr: OK I've updated the codepen and the 3rd box now has a
different baseline in browsers
smfr: Safari differs from everyone else.
fantasai: And Safari's behavior is what we resolved on.
Rossen: So this is what's defined in the alignment spec?
fantasai: Yup.
Rossen: Do we need to resolve anything further?
fantasai: Only if we want to change it, e.g. what we proposed or
change margin-box to padding-box.
Rossen: border?!
fantasai: padding!?
Rossen: Don't need to decide on border vs. padding right now.
fantasai: Trying to take spec to CR, need to close off the issues.
Could maybe decide after lunch though?
<br type="lunch">
fantasai: We discussed the last baseline of scrollable boxes, but
we need a resolution.
fantasai: The last thing I heard: suggestion: floor it at the
bottom border edge.
Rossen: <deliberately nods>
fantasai: 3 options: 1. leave it as is. 2. Change from bottom
margin edge to bottom border edge. 3. Scroll to the
final position, take the last baseline.
fantasai: Aforementioned suggestion is #2.
Rossen: What does "leave as is" mean?
fantasai: What the spec says now.
Rossen: Then there's no reason to do #1.
<dbaron> I'm happy with either #1 or #2; I think #3 has some
issues that would need to be sorted through.
<fantasai> dbaron, do you want to see those investigated?
<dbaron> fantasai, no need if we're just going to do #2
astearns: objections to #2?
RESOLVED: Change bottom margin edge to bottom border edge.
Received on Saturday, 27 May 2017 00:41:24 UTC