Comments (61)
I intend to make overflow:overlay be a synonym for overflow:auto in WebKit: webkit.org/b/189811 to reduce engine complexity.
from csswg-drafts.
What is the status of overflow: overlay
? I want to use it in an Electron app, and it works fine as far as I can tell. @smfr said he made it the same as overflow: auto
but that doesn't seem to be the case in the version of Chrome in Electron I am using (says it is Chrome 80).
from csswg-drafts.
We resolved on:
scrollbar-gutter: auto | [ [stable | always ] && force? && both? ]
The property is inherited, and the initial value is auto
.
The behavior of auto
, stable
, and force
is as defined in #92 (comment). They also apply when overflow
is scroll
.
Stable and always do not apply to overflow: visisble
, overflow: hidden
, and overflow: clip
, unless the force
keyword is present, in which case they do.
When the both
keyword is present, the space is reserved on both edges of the box rather than just the side the scrollbar appears in.
The property only has effects on the scrollbars triggered by overflow in the block direction.
If we find that we want to get the same effect for inline overflow, we will later add a new scrollbar-gutter-inline
longhand, and the shorthand optionally take the same values a second time, defaulting to auto
when omitted.
The name of the values are expected to be bikesheeded in a future session.
from csswg-drafts.
We've heard a bunch of feedback from web developers that they want this feature (eg. it makes it easier to reason about layout when content grows/shrinks in an overflow:auto container). So we do not plan to deprecate this API from blink.
from csswg-drafts.
Proposal:
Name: overflow-style
Values: auto | auto-hide | overlay
Initial: auto;
Applies to: same as the overflow/ overflow-x / overflow-y properties
Computed value: as specified
Animation type: discreetauto: scrollbars, if present, are drawn according to platform conventions.
overlay: scrollbars must not consume space. The UA should follow platform conventions as to the appearance of the scrollbar, but it must also make sure that underlying content remains visible, for example by making scroll bars transparent, or by automatically hiding them when the use is not actively scrolling.
auto-hide: For scrollbars caused by
overflow: auto
, this does the same asoverflow-style :overlay
. for scrollbars caused byoverflow: scroll
:
- the UA must reserve space for the scrollbar to ensure that it does not overlap with content.
- the UA must follow platform conventions as to the appearance of the scrollbar. Depending on platform conventions, the UA may make the scrollbar invisible when the use is not actively scrolling. If the scrollbar is transparent, or partly transparent, or sometimes invisible, the area under it is painted as if it were an extension of the padding area.
- If the scrollbar would be non-operable due to the element having no overflowing content in the relevant dimention, the UA must not display the scrollbar, but it must still consume reserve the same amount of space. This area is painted as if it were an extension of the padding area.
from csswg-drafts.
The cases we've seen developers choose to use overflow:overlay, they're careful to have sufficient padding-right such that the scrollbars don't actually overlap the content (though I guess this depends on the implementation detail of the default scrollbar width - maybe the spec should define a maximum). So I think that would be OK. Since there's already non-trivial use of this syntax on the web, if we agree the semantics are reasonable, the simplest thing would be to standardize it.
That said, there's additional reason to like the authiding-scrollbar behavior. I don't know offhand if the developers who wanted overflow:overlay would be content with autohiding behavior as the only option. I'd personally be happy standardizing both.
@esprehn, @tabatkins thoughts?
from csswg-drafts.
Whether or not something needs a scrollbar to show up when there's overflow is something you need to decide on an element per element basis.
What that scrollbar should look like is something that you may sometimes want to decide on an element per element basis, but you may also want to make page-wide (or widget-wide, or component-wide... .i.e non local) decisions, and that's a lot easier to do if they cascade separately. And it gives better fallback behavior when some values are not supported: auto
is a better fallback from stable
than visible
, which is what you'd get if you're not careful.
Based on that, I think that it makes sense for the values we are discussing now to be in a different property than the choice between visible
vs auto
. By that logic, it could make sense for the choice of scroll
vs auto
to be in that same other property as well, but too late for that.
from csswg-drafts.
First, one process oriented comment. The CSSWG uses the www-style mailing list for technical discussions, not github. That may change one day, but so far it hasn't, so we should bring this back to the ML.
Now, on the proposal itself.
Regardless of whether we use autohiding or not or both, I think using the overflow-style property makes more sense:
- Better graceful degradation. In a UA that doesn't support it you still get the correct value for the overflow property, which wouldn't be the case if we used
overflow:overlay
which would fallback on the default value, most likelyvisible
. - If you want to apply the same overflow style to many scrollers, it's much easier to get this to cascade separately:
* { overflow-style: overlay;}
#foo { overflow: auto; }
#bar, #baz {oveflow: scroll}
from csswg-drafts.
If I understand correctly, the current proposal is to have overflow: overlay reserve space for a scrollbar, only draw that scrollbar if it's "active", and intercept hit testing in the scrollbar region as if it were visible.
I think this defeats the purpose of overlay scrollbars. The whole point is to not take up any space, leaving more space for content. And for many types of content, it's just fine to paint in the area under the scrollbar (which is invisible most of the time).
The main problem comes with putting interactive content in that scrollbar area, like small buttons, where attempts to interact with the button end up bringing up the scrollbar. On Mac, at least, this is ameliorated by only showing the scrollbars when two fingers are on the trackpad, or you actually start to scroll.
from csswg-drafts.
No, what Rick suggested just above is that we start by just saying that overflow:scroll
is allowed to just... not paint the scrollbars if they're disabled. Keep the space, but don't draw anything. This should be a no-op for pages, but make overflow:scroll
less ugly, and satisfy at least one major use-case for "overlay scrollbars".
Whether or not that space intercepts hit-testing is an open question that I think is relatively unimportant. We should decide one way or the other when speccing it (or make it explicitly undefined and encourage browsers to experiment and report back), but it's not a vital question to answer while evaluating this option.
For content that's okay with the scrollbars overlapping, we can then talk about actually speccing overflow:overlay
. But this minor edit to scroll
is actually safer and arguably more commonly useful, and gets us what we want without having to worry about "platform conventions" getting in the way.
I think this defeats the purpose of overlay scrollbars. The whole point is to not take up any space, leaving more space for content.
I strongly disagree. That's one point, yes, and if that's the goal you need true "overlay" scrollbars. The other reasons for this kinda thing, though, are to prevent your layout from shifting based on whether or not a scrollbar shows. For this it doesn't matter whether there's some lost space on the side or not; you can adapt either way, you just want it to be stable. overflow:scroll
does that today, but at the cost of having an ugly disabled scrollbar when the element isn't scrollable, which is enough of a downside that people actively avoid that value and instead hack around overflow:auto
. So we can just fix that downside.
And if we do that, we can be more aggressive about designing features that treat overflow:auto
as always not having scrollbars, like vw
and friends do, because people can then just use overflow:scroll
if they want that space reserved. (Or overflow:overlay
if/when we spec that.) Simpler layout code, yay!
from csswg-drafts.
Right, but I don't think the correct thing is new values to the overflow property, but rather values to an overflow-style property.
- The fallback behavior in UAs that don't support this is better
- These things cascade separately
- Whether something has scrollbars or not (overflow: auto / scroll vs visible / hidden) is an independent question of how the scrollbars should look like.
I can also see Apple's point that authors should not have control over this at all. But if they should, I'm pretty sure it shouldn't be in the overflow property.
from csswg-drafts.
That's actually quite different. This overflow-style old spec defined a bunch of different UIs for scrollers, but in all cases it didn't say how they consumed space. This new property does not change the UI for scrollers but does define (and let authors influence) whether and how they control space.
from csswg-drafts.
A great addition to the overflow spec. Implementing the -ms- feature we were concerned that the overlay scrollbars on top of the content degrades reading experience quite a bit, thus the autohiding behavior.
What are you proposing that we standardize?
from csswg-drafts.
We have conversations in other venues about technical topics all the time, so I think it's fine to continue to discuss this here. The only requirement I'd like to have is that a summary be posted to www-style with a link back here. I'll bring this process detail up in the meetings next week.
from csswg-drafts.
Sure. I just mean that while IRC discussions and the like are understood by all as being informal, some groups actually do use github for decision making but not this one, so there is potential for confusion. As you say, as long as it comes back to www-style at some point, it's all good.
from csswg-drafts.
For WebKit I don't think we want authors to be able to force scrollbars to diverge from the system-wide behavior. overflow: overlay is a historical artifact added for a Safari feature many years ago (before the system had overlay scrollbars), and I don't really want to see standardized.
from csswg-drafts.
@smfr Does iOS currently use overlay scrollbars by default? Or layout-affecting ones?
from csswg-drafts.
iOS uses overlay scrollbars exclusively.
from csswg-drafts.
So if we specced this as hinting that the author wants overlay scrollbars (without implying that the default has to be non-overlay), I assume you'd be cool with it?
from csswg-drafts.
Is any UA willing to allow authors to change the types of scrollbars in different scrollable areas on a page?
from csswg-drafts.
We do that today, with overflow: overlay
, thus this thread asking for it to be specced. ^_^ IE has something similar. Check the first post.
from csswg-drafts.
In Sydney we discussed that it's probably not really the overlay property devs want but these two sub-properties:
- No layout changes on size changes (like overflow:scroll)
- No (ugly) visuals when scrolling isn't needed (like overflow:auto)
Could these properties be achieved without dictating anything that contradicts system appearance, and without introducing the "may cover content" (or "hard to grab with mouse") concern?
Eg. Maybe something like overflow:auto but that adds scrollbar-sized padding when no scrollbars are shown?
from csswg-drafts.
This sounds legit to me. Identical to overflow:scroll, but without actually drawing any scrollbar. +1
Wanna take this to the list for wider comment?
from csswg-drafts.
I'm happy to do that, but just before we do: if that's really what we want so we need a new API for it at all? I.e. is it possible it's web compatible to either stop drawing the disabled scrollbars for overflow:scroll? In what situation would a developer want to be able to request overflow:scroll instead of this new behavior?
from csswg-drafts.
There's absolutely zero page-observable difference between "draws the disabled scrollbars" and "reserves space but doesn't draw anything". So yeah, it's completely web-compatible. You wanna do that in Chrome, then we can add some text to the Overflow spec recommending that?
from csswg-drafts.
What if the page puts something there (e.g. abspos) with a click event handler? Seems observable.
from csswg-drafts.
Seems unlikely to be a problem, though. Also, you can make that area behave exactly the same as a transparent scrollbar, in which case it would be completely unobservable.
from csswg-drafts.
@smfr I assume you mean, like, underneath it, so the click event hits the element when it would otherwise have been intercepted by the disabled scrollbar?
If so, I agree with fantasai on both counts.
from csswg-drafts.
We discussed this a bit for blink and people pointed out that it's very common to have full-width content that would look weird if it didn't go to the edge of the container (see screenshots here). Since we can't automatically determine if the content is "background" (safe to overlap with a scrollbar when present) or essential UI, we can't just automatically do the right thing.
from csswg-drafts.
Yeah, I suppose I agree, unfortunately. :/
So we're back to needing new values to opt into good behavior, and never ridding ourselves of the terrible "overflow: auto" effect on layout calculations unless/until everyone agrees to switch to overlay scrollbars.
from csswg-drafts.
A related argument for overflow-style: I think there are legitimate use cases for disabling scrollbars entirely. Eg. a horizontally scrollable tab strip - @esprehn tells me polymer and facebook apparently rely on a hack for this where they place the strip inside a overflow:hidden container that is 20px shorter in order to clip the scrollbar. Some sites also rely on -webkit scrollbar theming for this. Edge has -ms-overflow-style: none
for this, we should standardize that too.
from csswg-drafts.
I'm confused - what part of this isn't already done by overflow:hidden? If you're just script-scrolling, overflow:hidden works just fine.
If you're wanting it to be pannable but not scrollable, that's a bit user-hostile - it'll only be scrollable on touch devices. Having something that turns off scrollbars when the user is capable of panning sounds okay, tho.
from csswg-drafts.
I'm confused - what part of this isn't already done by overflow:hidden? If you're just script-scrolling, overflow:hidden works just fine.
These scenarios are explicitly about avoiding script-scrolling (that's got a number of drawbacks, although it's commonly used for these scenarios).
If you're wanting it to be pannable but not scrollable, that's a bit user-hostile - it'll only be scrollable on touch devices. Having something that turns off scrollbars when the user is capable of panning sounds okay, tho.
Good point, though it's not just "touch" devices - you can still scroll with a mousewheel etc. Perhaps we need more concrete use cases here - presumably people are either breaking scenarios where scrollbars are the only way to scroll, or using this only as a convenience UI when there is some other navigation mechanism. eg. for a tab strip, you can click on the left or rightmost tab and it'll recenter to show more further left/right. The Android homescreen is an interesting use-case too - it doesn't have a scrollbar, but a custom "dot" indicator showing the active screen (and in mouse cases you could presumably click on the dot you want). Scenarios like this will probably be more common when developers switch to using css snap points (instead of custom JS scrolling) - those often have alternate navigation UI (at least next / previous buttons). Of all the image carousels I've seen on the web, I don't think I've ever seen one with a scrollbar. We want to support those scenarios as native scrollers right?
from csswg-drafts.
Good point, though it's not just "touch" devices - you can still scroll with a mousewheel etc.
If it's vertical, yeah. You explicitly mentioned a horizontally scrollable strip, tho. ^_^
We want to support those scenarios as native scrollers right?
Definitely. The hard part is designing things that degrade well, and making the badly-behaved things possible but not the easiest thing to reach for. ^_^
For example, a "panning" overflow-style could hide the scrollbars when the device is capable of panning, and default to showing scrollbars otherwise. We could then have a property controlling that default, and allow people to say they'll handle those cases manually, with a property/value name that makes it less attractive, defaulting to the safe scrollbar-showing behavior.
from csswg-drafts.
For example, a "panning" overflow-style could hide the scrollbars when the device is capable of panning, and default to showing scrollbars otherwise.
Or this could be Media query based.
from csswg-drafts.
MQs let authors vary styles. I'm not sure how they help us define default behavior of a value.
from csswg-drafts.
Sure. I'm just saying that showing scroll-bars when you have a mouse and have them invisible (not autohide) when you're on a panning device may not be a sufficiently common desire that we need to have a built in value to handle it, and if authors can use MQs to figure out they're on a device with panning, they can do it themselves.
from csswg-drafts.
Just realized / remembered another aspect of overflow:auto
which sucks when the overflow-style
isn't overlay
: vertical scroll bars aren't taken into account for inline intrinsic sizing (cause they can't):
pre {
max-height: 100px;
overflow-y: auto;
width: max-content; /* or width: min-content,
or float:left
or position:absolute
or <td><pre>...</pre></td> */
}
This gives you a horizontal scrollbar in addition to the vertical one when there's vertical overflow, which is not what the author wants (typically). This wouldn't:
pre {
max-height: 100px;
overflow-y: auto;
overflow-style: overlay;
width: max-content; /* or width: min-content,
or float:left
or position:absolute
or <td><pre>...</pre></td> */
}
from csswg-drafts.
The goals with the suggestion above is double:
- give authors all they need: both the ability to opt into scrollbars that don't take space, and into scrollbars that do take space but don't look ugly when there's no scrolling to do, while at the same time also
- All browser vendors to match continue to match platform conventions. On platforms that have overlay scrollbars by default: the native appearance is always preserved, and the property only changes whether the scrollbar also takes space. In Platforms that have non-overlay scrollbars by default, the appearance is preserved for the auto and auto-hide values in all cases, and if the platform also has (opt-in) overlay scrollbars, it uses that appearance for overlay as well.
from csswg-drafts.
I think overflow: auto-hide
should behave the same for overflow: scroll
and overflow: auto
when there is sufficient content to scroll.
from csswg-drafts.
If the width of the scollbar is known to CSS an author could write,
margin-left: max(1em, --ui-scrollbar-width)
or whatever, and reserve space accordingly. That might be better than a new property.
The main difficulties I see is are
- you don't know whether the scrollbar will be on the left, right, top, bottom, depending on language writing mode and user locale and preferences.
- the box model needs to be clear that the scroll bar comes out of margin (or padding) space. Maybe that's already clear?
- we don't actually have max()
from csswg-drafts.
Results of the telcon, in my words:
- The WG is in agreement that the problem to solve is eliminating the "jiggle"/relayout that occurs due to "overflow:auto" adding a scrollbar (and thus reducing the space available for content) only when the content overflows.
- Forcing overlay scrollbars is one way to accomplish this, but Apple is opposed to that (as they consider overlay-or-not to be a choice firmly in the user's hands), and Chrome would likely have issues pushing that scenario on Windows UI, too.
- Boiled down, then, what we absolutely need is a value that reserves the same amount of space whether the scrollbar is shown or not.
- There's a subissue regarding overlay scrollbars: if the system uses overlays, should it still reserve the space that intrusive scrollbars would require? Both sides have useful arguments: "no" gives minimal disruption, making this value identical to the other scrolling values when the user wants overlays; "yes" is a common request of authors, who want to ensure that no content sits under the scrollbar even during transient scrolling.
Thus, I propose two values (names pending):
value1: Acts like "auto" (doesn't show a scrollbar when the content doesn't overflow), but when using intrusive scrollbars, reserves the space the scrollbar would take up if it was there. (Overlay scrollbars continue to take up zero space regardless of content size.)
value2: Acts like value1, but reserves the intrusive-scrollbar size at all times, even when scrollbars are overlay.
We should then permanently shelve the idea of standardizing the "overlay" value, and commit to "overlay vs intrusive" being a user/platform choice uncontrollable by CSS.
Parallel to this, we should restart the discussion of a "scrollbar width" unit or keyword, so people can reserve space on both sides of an element.
Parallel to this, we should discuss if Houdini Layout'd elements always require a "stable" overflow value, such that "overflow: auto" is treated as one of the above two values (probably value1) on Houdini'd elements. That would let us chop out a big chunk of complexity from the layout API that authors will probably usually get wrong anyway.
(I'll internally start a discussion about whether Chrome might want to switch auto
's behavior in general to match one of these values, again probably value1, so that we never have unstable scrollbars.)
from csswg-drafts.
We should then permanently shelve the idea of standardizing the "overlay" value, and commit to "overlay vs intrusive" being a user/platform choice uncontrollable by CSS.
Oooh, or, since at least Chrome/WebKit already have the overlay
value, define that it's an alias of value1
, and deprecated.
from csswg-drafts.
Now that this property is just about reserving space, I don't think " overflow-style" is a good property name. It's more like "scrollbar-gutter: auto/when-scrollable/always;"
from csswg-drafts.
Dang yeah, that's pretty good. Tho overflow-gutter
just to keep it under the overflow
umbrella. And maybe stable
instead of when-scrollable
(which is both long and a little difficult to spell).
from csswg-drafts.
This all sounds great, but I'd like to also reopen @RByers's earlier request to including a way to hide overlay scrollbars entirely and reserve no space. This is useful for image carousels, chat boxes, and for replacement by JS bespoke scrollbars for contact lists and photo albums. Without vendor prefixes, it can only be achieved with complex, bug-prone box tricks or touch-handler fake scrollers.
@tabatkins's objection was that we don't want to make it too easy to make sites unusable for users who prefer to click on the scrollbar, and he suggested:
For example, a "panning" overflow-style could hide the scrollbars when the device is capable of panning, and default to showing scrollbars otherwise.
I think tying this to input capabilities is too weird. Some somewhat saner variants would be to tie it to overlay-or-not, or possibly scrollbar-absorbs-clicks-or-not.
But, personally my preference would be to just have a value3
that hides any scrollbar entirely and reserves no space, as I think having a rational platform is most important here. I've yet to run into a site abusing the existing vendor-prefixed properties to accidentally hide a useful desktop scrollbar, so I doubt standardizing the capability would lead to a problem either.
from csswg-drafts.
Now that this property is just about reserving space, I don't think " overflow-style" is a good property name.
I agree.
It's more like "scrollbar-gutter: auto/when-scrollable/always;"
Dang yeah, that's pretty good. Tho overflow-gutter just to keep it under the overflow umbrella.
Then again, overflow-gutter (or overflow-style for that matter) incorrectly suggests that this may be a longhand of overflow. So maybe we're better off without an overflow prefix.
And maybe stable instead of when-scrollable (which is both long and a little difficult to spell).
Agreed. I had been looking for names for your value1 and value2, and also landed on stable for value1. And if the property is called ...-gutter
, always is pretty good for value2.
I'd like to also reopen @RByers's earlier request to including a way to hide overlay scrollbars entirely and reserve no space [... but not the same as overflow:hidden, because it would still respond to the scroll wheel or touch panning ...]
I have no strong opinion for or against this part, but if we want it, it feels like it would influence the property and the other values' names. hidden or invisible sounds like an OK name for this value3, but not under a property called ...-gutter. And since that part of the name was what made it possible to call value2 always, if we do want this value3 we have a bit more bikeshedding to deal with.
scroll-style: auto | stable-gutter | always-on-gutter | no-scrollbar
Meh, that's lousy.
Also, I am not sure what that implies in terms of bikeshedding, but other than auto, all these values make overflow:scroll
and overflow:auto
identical to each other. Maybe overflow:auto should never have existed, and we should have had overflow:scroll; scroll-style: on-demand
instead. But that ship has sailed a looooong time ago.
from csswg-drafts.
Since it sounds like we're converging on some gutter-defining API, I split the "mechanism for disabling scrollbars" debate off into #419.
from csswg-drafts.
Bikeshedding a bit more, I think I like:
overflow-gutter: auto | stable | always
(and none
if we end up accepting #419)
All of these values only have effect when overflow
is auto
:
auto
would give us today's behavior (or, if it turns out we can change it, act likestable
)stable
is the "zero space if overlay, always space if intrusive" behavioralways
is the "always space as if it's intrusive, even if you have overlay" behavior
If people don't have objections to these, I'll write them up proper in a spec.
from csswg-drafts.
Rather overflow-gap
to match grid-gap and multicol-gap?
from csswg-drafts.
Hahaha, yeah, sure.
from csswg-drafts.
It's actually a substantially different concept--more like the gutters used for bookbinding, not really a gap between things. So gutter seems better imho...
from csswg-drafts.
Whether we call the the property -gutter or -gap, the three value version (auto | stable | always) seems good to me.
Adding none
if we end up accepting #419 seems a little bit weirder. It suggests we don't have a gap/gutter,
when what we don't have is a scrollbar. That said, while I find it a bit odd, I wouldn't object.
from csswg-drafts.
@fantasai Even if the concept is a bit different (I agree, it is), it's close enough that converging on names is worthwhile. The semantic difference between "gap" and "gutter" is razor-thin - this is indeed a gap between the outer edge of the padding box and the inner edge of the border box. I don't like forcing people to remember precisely which way we were leaning in the wind at a given time, even if one can argue that something is slightly more appropriate; better to be consistent and slightly wrong, than inconsistent but completely correct.
@frivoal Yeah, I'm not in any way attached to expressing the "no scrollbar" functionality thru this, I was just pointing out that we have a reasonable name available if we do indeed go that way. It's not part of the current proposal.
from csswg-drafts.
I don't actually conceive of this as a “gap” at all: it is filled by the scrollbar. So to me it doesn't even seem close to right.
from csswg-drafts.
Bikeshedding aside, following the last conf call, we now have 3 proposals:
- Have the 3 values (auto/stable/always) attached to a separate property that is not a longhand of overflow. e.g:
scrollbar-gutter: auto | stable | always
- Have the three values attached to an overflow-something property that is a longhand of overflow. e.g.
overflow-gutter: auto | stable | always
- Have the two non default values (stable/always) be optional values directly on the overflow property. e.g.
overflow: visible | hidden | scroll | auto [stable | spaced]?
In all cases, if we decide to accept #419 as well, we can add the additional value.
I prefer solution number 1, because it makes sense to me that this would cascade separately (which makes it better than 2 and 3), and also because this seems more robust with regards to dealing with fall back behavior in browsers that don't support this property (which makes it better than 3).
from csswg-drafts.
I don't understand why this needs to cascade separately. This isn't an independent piece of behavior - it's modifying the behavior of one value in 'overflow'. Effectively these are just two new 'overflow' values; the argument against actually doing that is that 'overflow' is already overloaded in handling multiple overflow-related things, and adding more values here would just increase the confusion.
In other words, there's no reason for the user to set "overflow: auto" if they really want the stable/always behavior. It doesn't offer them anything additional; it doesn't make their life easier for some other reason. They should just be setting the "stable" or "always" value directly on those elements, and only use "auto" if they actually want "auto" behavior.
from csswg-drafts.
Time to revisit? Agenda+ing
from csswg-drafts.
I agree with Florian here.
from csswg-drafts.
from csswg-drafts.
People, am I the only one having a déjà vu? Much of what's discussed above was once drafted in [css-box]: https://www.w3.org/TR/2007/WD-css3-box-20070809/#the-lsquo3.
from csswg-drafts.
Related Issues (20)
- [css-animation-1] Should non-animatable properties be accepted in keyframe rules?
- [css-ui] Proposal: allow multiple outlines per element HOT 2
- [cssom-view] Change `document.caretPositionFromPoint`'s `shadowRoots` parameter from rest parameter to an array HOT 9
- [cssom-1] A more direct method than `caretPositionFromPoint()` HOT 2
- [css-contain] content-visibility: auto and SVG-as-image HOT 9
- repo name nit: it'd be nice if this were simply w3c/csswg HOT 1
- [css-color-4] Clarify used value of currentColor HOT 3
- [css-syntax] "Consume a declaration" (5.5.6) leaves out a final "else" condition?
- [css-values-5] should 'calc-size(0)' work? HOT 2
- [css-values-5] Consider supporting `calc-size()` in the `inset` property HOT 2
- [selectors][css-transitions-2] `:starting-style` pseudo-class HOT 10
- [css-grid] respect `justify-content: center` even when column width is fluid and has max-width using `auto-fit/fill` HOT 1
- [css-syntax] Concrete criteria for rule / declaration validity when being produced by a [compliant] parser? HOT 4
- [css-color-5] Clarification on `none` components in relative color syntax. HOT 1
- [css-anchor-position] Drawing irregular shapes between two items HOT 1
- Custom state pseudo classes are changing from ":--muted" to ":state(muted)" soon???
- [css-text-3][css-text-4] Japanese small kana and `line-break: normal` HOT 1
- [css-view-transitions-2] Support same-site cross-origin view transitions HOT 10
- [css-anchor-position] Make anchor-center work without position-anchor HOT 2
- [css-colors-4] Clip negative whiteness/blackness of `<hwb()>`? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from csswg-drafts.