Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[css-ui-4] Define appearance:base #10691

Merged
merged 9 commits into from
Sep 17, 2024
Merged

[css-ui-4] Define appearance:base #10691

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
74d1b37
Add spec for appearance:base
josepharhar Jul 25, 2024
199e2ee
revise text
josepharhar Aug 5, 2024
3abcc08
remove additional styling capabilities
josepharhar Aug 6, 2024
99fce6c
add missing dl end tag
josepharhar Aug 21, 2024
8871a76
nits
josepharhar Aug 21, 2024
bed0caf
add issue text
josepharhar Aug 22, 2024
aa53cbf
add style adjusting based on appearance
josepharhar Sep 10, 2024
c1dd0fb
revise issue text
josepharhar Sep 17, 2024
9666542
update text for elements other than widgets
josepharhar Sep 17, 2024
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
remove additional styling capabilities
  • Loading branch information
@josepharhar
josepharhar committed Aug 6, 2024
commit 3abcc08268f3e410523f1c4eee6a645a275831ac
7 changes: 3 additions & 4 deletions css-ui-4/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2138,10 +2138,9 @@ Switching appearance: the 'appearance' property</h3>
Using ''appearance: base'' gives <a>widgets</a> a <dfn export>base
appearance</dfn>. <a>Widgets</a> in <span>base appearance</span> have their
<a>native appearance</a> suppressed where CSS can be used to restyle them,
just like <a>primitive appearance</a>, but also have additional styling
capabilities and default styles which are usable and interoperable. This is
unlike <a>base appearance</a> which can cause some <a>widgets</a> to
disappear completely.
just like <a>primitive appearance</a>, but also have default styles which are
usable and interoperable. This is unlike <a>base appearance</a> which can
josepharhar marked this conversation as resolved.
Show resolved Hide resolved
cause some <a>widgets</a> to disappear completely.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we have to define the style system magic here or elsewhere that makes this possible?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't necessarily define the specifics of it (seems like an implementation thing), but maybe just at least the end result?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it has to define that a widget can have some style sheet associated with it (that is defined wherever that widget is defined) and how resolving that style sheet with the existing user agent style sheets and any author and user style sheets is supposed to work.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think I agree that we need to define a bit more here, since (unless I'm misunderstanding the current plan) I think this is going to cause some styles to get applied that change the computed values of other properties, both on this element and likely also on observable pseudo-elements inside of it.

(On the flip side, I think the current plan is that appearance: base doesn't change whether any pseudo-elements exist (if such a thing is even detectable) since it doesn't change the UA shadow DOM at all. (But I think it does change whether some parts of the UA shadow DOM are display:none or not.) At least, I think that's the current plan, and it certainly does make things cleaner architecturally even if it requires some local ugliness in places.)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, yes, the internal shadow tree plan would be good to clarify as well.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So should I add a paragraph that looks like this?

A widget can have some style sheet associated with it and those styles can change based on whether the widget has a native appearance, primitive appearance, or base appearance.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible that we only want the style sheet variation to occur between base appearance and the other values. I think the difference between native appearance and primitive appearance has historically not shown up in the computed values of the properties (e.g., border) that are affected. (Though I'm not 100% sure of this.)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this?

A widget can have some style sheet associated with it and those styles can change based on whether the widget has a base appearance. Native appearance and primitive appearance should have the same styles.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I added the text I suggested in my last comment

<details class=note>
<summary>Note on the history of this feature</summary>
Expand Down