-
-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a formal mapping of Pack->CSS #1778
Conversation
… root view testing easier.
996cf23
to
f381494
Compare
2a7533a
to
f539e23
Compare
f539e23
to
55fde14
Compare
Based on my experiments, this is only the case: when quirks mode is active, which happens when the document contains no DOCTYPE, or a very old one. I think this is what was happening with your test document on Thursday. With So it looks like we should add the following rule:
I'll post the rest of my review tomorrow. |
Agreed that quirks mode was the problem here; the |
7f2e182
to
3c52027
Compare
I've done some more fiddling with quirks mode, and updated the mapping definition to include a full reference HTML document. I've also added Based on those changes, Tutorial 0 becomes:
and Tutorial 1 becomes:
(This tutorial 1 example has slightly different margin values, but the effect is the same). Interestingly, I think I've found a bug in Chrome (109.0.5414.119) around the handling of margin collapse on the root element. Opening the document in a new tab always gives the correct rendering; however, |
core/src/toga/style/pack.py
Outdated
if self.flex: | ||
css.append(f"flex: {self.flex} 0 0%;") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This contradicts the definition of flex
in pack.rst, which says that an explicit size in the main axis should cause flex
to be ignored. Is that the current Pack behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe I was relying on the fact that a flex definition will be ignored if width/height are defined. However, to avoid confusion, it's probably better to merge this into the width/height constructions above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on my tests, both flex: 1 0 0
and flex: 0 0 0
do have an effect in CSS even if there's an explicit width/height
, so we'd better only generate either flex
or width/height
.
Co-authored-by: Malcolm Smith <smith@chaquo.com>
I think there will be some overlap between the GTK changes and what I'm working on for Android. So I've reduced this PR to the CSS mapping changes, which I'll merge now, and I'll make a separate PR for the GTK changes (#1794). |
The Pack layout was somewhat confused around how it was meant to behave with the "root" content of a layout. Using HTML as a model, the "root" content is the
<body>
element; and that element is always the size of the display window. Previously, Pack would only assume the full size of the window if the root content had no children; as soon as the root content had children, the flex axis (i.e., vertical in a Column box, horizontal in a Row box) would be shrunk to the minimum possible size. This led to interesting situations where a Column layout would be flexible in height, but wouldn't expand to the full height of the window. It would also lead to background colors not being applied over the entire background.This PR makes an attempt at a policy statement at the intended Pack->HTML/CSS mapping as a source of reference, and then implements some changes to the handling of the root element that reflects those changes.
[Remainder moved to #1794. – @mhsmith]
PR Checklist: