- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Aug 2016 21:35:08 -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 Pseudo Elements & CSSOM items
---------------------------------
- RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom)
from the current level 4 draft and move the work to
Houdini
- Rossen was actioned to open an issue on Box 3 for Houdini
Should Device Adaptation include a normative definition of <meta>
viewport?
---------------------------------------------------------------------
- RESOLVED: Change the <meta> viewport text to normative and add
two issues. One to test if the description matches
reality. Second is while we spec with the same
mechanism there may be differences as we tease out
compat.
box-suppress name and shorthanding relationship to 'display'
------------------------------------------------------------
- RESOLVED: Make display into a short hand and add an issue on
naming for the long hands.
Overflow: Consider support for overlay scrollbars
-------------------------------------------------
- Florian brought his proposal to create
overflow-style: auto|auto-hide|overlay to allow authors more
control over scrollbars while balancing out the desires of
implementors to control their scrollbars.
- There was a feeling that this was still too problematic and
auto-hide and overlay should be merged into one value that
behaves depending on the platform behavior.
- The group was heading in the direction of creating value that
reserves the same amount of space whether the scrollbar is
shown or not in order to solve the re-layout problem, but ran
out of time so conversation will continue on github.
====== FULL MINUTES BELOW ======
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Dave Cramer
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Michael Miller
Anton Prowse
Florian Rivoal
Jen Simmons
Alan Stearns
Liam Quin
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Daniel Glazman
Chris Lilley
Scribe: dael
CSS Pseudo Elements & CSSOM items
---------------------------------
<astearns> https://drafts.csswg.org/css-pseudo/#cssom
astearns: Let's get started.
astearns: Does anyone have anything extra to add to the agenda?
astearns: This is a hold over from last week as to if we should
drop the CSSOM part.
Florian: Should move to next level.
astearns: There isn't one. My preference would be if we drop we
start a new level so that it has some place to go. We
know we need to work on it.
fantasai: Given that the whole section is a bunch of issues
including design level issues I would prefer to leave it
as an open issue on the issues list and link it to
whatever proposals we have. This is on the TR page. We
can have it as an open issue on github.
fantasai: If someone wants to go through it and create a real
proposal I'm happy to keep it or have it in 5, but if no
one is going to work on it I'm inclined to that.
astearns: There's working on the API and working on implementing
any portion.
fantasai: If the API is close I'm happy to hang on to it, but
based on the issues it seems like a random proposal that
as the spec author I'm not sure is a good idea. It may
lead people wrong or in a specific direction when we
don't have one.
Florian: If this is so vague how is it under TR?
fantasai: It was somewhere else and when I drafted pseudo elements
it got scooped in.
astearns: I think it was always in pseudo elements and we removed
other even more unlikely things before TR, but this was
left.
fantasai: If someone wants to work on it or has reviewed it and
think this is a good general approach I'm fine.
Florian: If we move entirely off the spec to an issue in github...
it's not one big issues it's a set of things. If we
collapse that to one thing it stifles the lower level
issues.
fantasai: I think to address the lower level we need to do the
higher level of is this even what we want. Picking the
paint before you decide you want a house instead of a
school is a bad idea.
Florian: Or you can flesh it out and see if it makes sense.
astearns: The issue about not sure on direction I wanted someone
besides me to look and see if it's the right direction
and that hasn't happened. Is anyone besides me
interested in working on this section?
* TabAtkins has too much stuff on his plate, tho he's interested.
Florian: Theoretically...I haven't reviewed it...but there's
another bit of OM stuff which is how pseudo elements and
the selections OM work together. Does it have anything
about that?
fantasai: No. For selections a lot of that is covered in other OM
specs.
Florian: Currently just it's not possible. But that's a problem.
astearns: The current bits of the OM are about accessing the
pseudo element. It's a first step.
Rossen: I joined a bit late, but did you discuss moving it to
Houdini? This is fairly applicable type of functionality
we're doing there. Like exposing boxes and stuff not
backed by DOM elements?
astearns: Perfect timing. I was going to bring that up.
Rossen: I'm interested in working on it, but that's my preferred
path.
fantasai: I'm fine with that.
Florian: As to interested, to the extent this allows selections on
pseudos I'm interested.
astearns: Let's resolve on removing this from the current level 4
draft and moving the work to Houdini. Objections?
RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom)
from the current level 4 draft and move the work to
Houdini
<dbaron> Is it going to move to an actual document in houdini?
<TabAtkins> Well, I think it'll move into a new WICG repo with the
intention of it "maturing" into Houdini.
Florian: Does Houdini inherent the context of relationships with
other groups from CSSWG?
astearns: My assumption is inherit from CSS relationships.
Florian: So we can talk to everyone.
astearns: Which Houdini doc does this move to, as dbaron asked?
Rossen: I would assume this is the Box 3 spec that doesn't have
anything actionable. But bringing in something like this
would make it actionable. So I think Box 3 spec.
astearns: Could I action you to open an issue on the Box 3 spec?
ACTION Rossen open an issue on Box 3 spec to include the pseudo
information
Should Device Adaptation include a normative definition of <meta>
viewport?
---------------------------------------------------------------------
Florian: Background: There's 2 theories on setting the viewport
size. The widely deployed <meta> viewport and CSS's
@viewport. <meta> came first, @viewport was a response.
Florian: <meta> viewport doesn't have a normative spec. There's an
informative section in @viewport with a fairly detailed
description.
Florian: The first point is I think there should be a normative
description for <meta> viewport. Second item is, is this
the right place to do it? To say that you have to
understand the spec. It describes a concrete CSS syntax
for @viewport and a separate section called constraining
procedure that says once we have values how does it
effect the @viewport. And another section for if you have
<meta> viewport how does it translate.
Florian: How @viewport was defined it's a bit short of <meta>
viewport.
Florian: First I'd like to hear if people want a normative
description. If yes, should we take the small extension
to the abstract and include it in the main. Turn the
informative section into a normative section with a
disclaimer that if there's discrepancies they should talk
to us.
Florian: I have other things, but I'll let others express thoughts
first.
<fantasai> I'm in favor of having a spec for this thing somewhere,
and this seems the best place.
dbaron: I think...I couldn't quit hear... <meta> viewport has
quirks that may or may not be copied to @viewport. We
should make explicit decisions on that instead of assuming
one thing or the other.
Florian: I think this is a fair point. It's possible the
description is out of date and there also may be quirks.
We should put an issue there. Anyone can dive in and try
to ID which parts are good, which is odd, what's
universal. There's a fair amount of testing in the wild,
but not our format. The knowledge should be out there.
Florian: I'm saying we flip from informative to normative and add
prominent issues.
astearns: This seems like the right place to put this info, so I'm
in favor of Florian's proposal.
<fremy> Florian: +1
Florian: Two other things. There have been some discussions as to
if the @viewport syntax isn't pre-loader friendly. Also
maybe that it's needlessly expressive. This isn't in
contradiction of what we've said now...this isn't about
the mechanism behind it. We may change the @viewport rule
syntax later. But since syntax and how it works is spec
separately it shouldn't effect our discussion, but it's
worth pointing out.
bradk: Can the <meta> be normative and deprecated? It's there for
compat but we want @viewport to take over for authors.
<astearns> probably a bit premature to deprecate anything
Florian: Maybe. The concerns about <meta> being preloader friendly
and @viewport isn't so I don't think there's universal
opinion to phase out <meta> viewport. Eventually, but the
time isn't right.
bradk: It's odd we're specing HTML.
Florian: Yes, but what that thing does is about layout and
viewport.
bradk: But we don't spec font tags.
Florian: No one specs this. There's already a description in the
spec for parsing.
TabAtkins: We're specing a <meta> tag that's an extension tag.
It's reasonable for us to spec a given <meta> tag.
bradk: You're saying it's not HTML specific.
TabAtkins: The meaning of the <meta> values is mostly defined by
other specs that are using it as a generic transfer
method.
Florian: So we have two ways to deal with the viewport, one of
which is CSS specific and one is a micro syntax.
Florian: Meta is all over the place in terms of deployment.
bradk: I understand the need for compat. I have no objection - it
just seems weird and backwards looking.
astearns: Other opinions?
smfr: I'm okay with making it normative. The spec needs to say
what happens if meta and @viewport are present.
Florian: It does.
smfr: The preload problem is serious so I don't think we at webkit
would be interested in dropping <meta> until that's resolved.
Florian: That doesn't surprise me.
smfr: Definitely there's a lot of compat issues with <meta>
viewport tag so we have to be careful.
Florian: There is a detailed and careful language, but I'm sure
the problem space is thorny enough we're missing things.
We need to start testing and find where the
implementations disagree. I think you should have a quick
look, it's fairly decently detailed. I don't think we can
get further without poking.
Florian: We do have pokers, though.
smfr: The parsing algorithm looks like it was reverse engineered.
That should be exposed in webkit now.
Florian: Fair enough. I don't know if everyone parses the same way.
Florian: By saying it's normative I don't expect the definition to
be final.
astearns: Proposal: add normative text describing the <meta> tag
with...
Florian: Not adding. Change the text from informative to normative.
astearns: Okay. With two issues. One to test if the description
matches reality. Second is while we spec with the same
mechanism there may be differences as we tease out
compat. Is that correct?
Florian: Not exactly what I was thinking for the issue, but a good
alternative. Let's go with that.
astearns: Objections?
RESOLVED: Change the <meta> text to normative and add two issues.
One to test if the description matches reality. Second
is while we spec with the same mechanism there may be
differences as we tease out compat.
box-suppress name and shorthanding relationship to 'display'
------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/343#issuecomment-235961589
fantasai: There has been an open issue on renaming box-suppress
property. One discussion that came up was that the
reason for having the display-or-not property be
independent of display was to put a rule for hidden in
the UA stylesheet and this would have an effect despite
authors having display property in their stylesheet.
fantasai: That's probably not something we can do at this point.
Hidden is implemented as display: none and authors have
adapted to override hidden using something like opacity.
So main reason for separation is no longer valid.
fantasai: Proposal is to make display-or-not a sub-property of
display.
fantasai: Other reason for splitting was to make authors not say
display inside and display outside separately. We can
solve that by having display-as property. So we'd have
display with display-type and display-as and display-box
or whatever we call that.
fantasai: The advantage is we don't have display:none as its own
thing that doesn't interact with display or not.
fantasai: The disadvantage is authors currently using display
won't be able to auto switch unless their selector for
that declaration is more specific.
fantasai: I think this would be an appropriate use of !important
would be to set something like hidden attribute
display-or-not: none
fantasai: So 1) redo short handing relationship. 2 & 3) name
sub-properties
Florian: One place I'm not clear. Why do we want to merge display
inside and outside?
fantasai: Authors want to set them at the same time. Right now
display sets inside and outside together which is what
you want. display-or-not is a separate property. If we
merge it back then any time you say display: table or
whatever it resets none to its initial value.
Florian: Got you.
Florian: Generally makes sense to me. The cascading with
!important makes me a little skeptical, but it might be
right
fantasai: It fits together better. It's mainly historical thing.
We didn't have that independent not-none switch.
Florian: Okay. I like it.
<fremy> @fantasai @astearns: why not extend visibility:collapse,
in case this is closer from what we want?
astearns: fantasai, did you see fremy comment?
fantasai: Partly that's sometimes what you want. This is effecting
all media. display: none takes the box from the box
tree. Sometimes we want visibility: flat. There's a
proposal for hide that keeps the element in the box
tree, but not effect layout in any way. The main
advantage is it tells you this will be a dynamic thing.
fantasai: Another advantage is it keeps track of animation timers.
So if you hide and show you haven't lost your timer. It
keeps counters in place as well.
fantasai: That's just a proposal right now. It would make sense to
have that in the display property.
astearns: I think this proposal makes sense. As a way to design
all these interaction this is the way to go.
astearns: I'm wary because we're talking about legacy with display
and display property is used EVERYWHERE.
fantasai: Existing style sheets won't be effected. If you decide
to start using display-or-not property you have to know
that rule is more specific. Which you'd have to do
anyway.
Florian: Or you need to stop using the shorthand and use the
longhands.
fantasai: Right. The current solution is the make sure your
noneness is specific or you use the longhands and
shorthands we're introducing here.
<fremy> @fantasai People will use libraries which are not
compatible, and this will make it harder than it should
Florian: I like it. I don't have a good name.
<jensimmons> I assume this is all to get us to a place where we
have a CSS property to let everyone write one line of
CSS to accomplish what the industry does now with a
hack — .element-invisible { position: absolute
!important; height: 1px; width: 1px; overflow:
hidden; clip: rect(1px 1px 1px 1px); } — yes?
<fantasai> jensimmons: yes, exactly :)
<jensimmons> visually hidden
<jensimmons> element invisible
<jensimmons> visual display
fantasai: We don't have a great name. display-box was suggested. I
think there were some others. Anyone with a suggestion
please put it in IRC.
astearns: display as a short hand...display-or-not is available ^-^
fantasai: This is true. :)
* jensimmons thinks ‘box’ is odd. Most people don’t think of these
items as boxes, even if technically they are
astearns: Objections or concerns about going in this direction?
Florian: One question. Where does display: content go in terms of
the long hand?
fantasai: I believe it's display-outside. It used to be a property
on display-or-not, but it's more of a display type then
hiding or showing. It wasn't an intuitive decision, but
we thought about it for a bit.
Florian: Makes sense. Then we could actually use display-or-not
even though it was a joke.
fantasai: The values on this property have to be about display
this box or not. Anything more complex has to go
elsewhere. I think about it as display-or-not for that
reason.
Florian: Do we have other properties that take a boolean?
fantasai: This isn't necessarily a boolean.
astearns: Proposal: Make display into a short hand and add an
issue on naming for the long hands.
astearns: Objections?
Florian: Ship it.
RESOLVED: Make display into a short hand and add an issue on
naming for the long hands.
Overflow: Consider support for overlay scrollbars
-------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/92
<fantasai> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-236550745
Florian: That's me. We've been discussing overlay scrollbar and
having control. Different OSes do it differently. There's
when it always takes space, it's when they disappear when
they're not used. There's desire from authors to control
that and desire from vendors to not allow that because
you get bad behavior.
Florian: There's a third dimension where the author doesn't care
on looks, but when you're in an overflow auto situation
don't display the scrollbar if not used, but give it
space.
Florian: The proposal is linked above.
Florian: Recycle the overflow-style property with values
auto|auto-hide|overlay. Auto is the initial which is
follow the style. Overlay requires the scrollbars to not
take up space.
Florian: Windows has an overlay scrollbar, just not as the default.
Florian: auto-hide if you're overflow auto it's the same as
overlay. For overflow scroll it does a few things. The
space for the scrollbar must be reserved. You take the
space for the scrollbar and if the element isn't
scrollable you don't display the scrollbar.
Florian: Why it's on overflow-style is that these things should
cascade separately. The style you want is different than
where you want them.
Florian: Yea/nay/questions?
<dbaron> the 'auto-hide' value seems weird
smfr: I think this is still treading on platform conventions. If
you have a mouse with a scroll wheel you get space reserving
scrollbars. It's also a setting in preferences.
Florian: Yes...
smfr: I think we discussed in Sydney and this still allows authors
to override users scrollbar choices which I don't agree with.
Florian: I've tried to minimize that tension. I'm not sure how to
provide the things authors want without completely
getting in the way of consistency for vendors.
astearns: Authors want to be able to say reserve space for the
scrollbars so I don't get re-layout. Is that right?
Florian: It's one aspect.
astearns: There are authors that want to control the scrollbars.
Is there a way to give them control without overriding
the users?
TabAtkins: I think that's what auto-hide does. And I agree with
your characterizations. That's what our impl want too,
to never have to worry about scrollbars.
Rossen: With auto you still have that problem. We had that in
older IE where we had the area for the scrollbar reserved
for the top scroller. It's weird but I can see why people
want it.
* jensimmons uses a wacom tablet — in Safari, the scrollbars are
the same as when I don’t have it plugged in. In
Firefox, it switches to oldschool scrollbars that
reserve space all the time & show the scrollbar all
the time. Just FYI. (We tripped over this when making
a tool for Grid in Firefox, unexpected scrollbars.)
Florian: I'm hearing that the way out is to merge overlay and
auto-hide and that depends on platform. So it'll either
overlay or be space consuming and not appear when not
needed. But either way it won't consume the layout
TabAtkins: It seems odd. I'd like to pursue getting the width of
the scrollbars which is something else people want. But
if you can't predict having it you can't control
spacing. Having a plain auto-hide that reserves space
and we have the other that always shows. So we can
guarantee no re-layout and when possible takes no space
but we have the always takes space value.
Florian: I could see that.
<liam> +1 to TabAtkins
Florian: smfr would that work?
smfr: Let me reword...If the scrollbar is a normal scrollbar,
always visible, do nothing. If overlay allows the author to
reserve the width of the scrollbar space.
TabAtkins: Slightly different. auto-hide value from Florian where
you always reserve space for the scrollbar even if it's
not drawn.
Rossen: So this is like overflow: scroll but up to the platform if
you show the scrollbar
Florian: It has two differences. On OSs that have overlay
scrollbars, they don't consume space. This requires they
do.
Rossen: No. The size of the overlay scrollbar in layout is 0. You
can consume 0.
TabAtkins: We're saying you consume the normal width for a
non-overlay scrollbar.
<bradk> It would require reserved space even when no scrolling is
necessary?
Rossen: Okay. Now I agree it's weird.
TabAtkins: We want to give authors a predictable width that
doesn't change due to content or user preference. They
have a predictable and usable geometry to work with
without something shrinking outside their control
* liam wonders whether overlay scrollbars and "traditional" ones
are always the same width, and how you know which side
they'll be on
<bradk> Sounds horrible
<dbaron> trying to make something that doesn't change based on
user preference is silly when it changes as a function of
OS and OS version
<fantasai> Why don't we just make this the default behavior of
`overflow: scroll`: Don't paint the scrollbar unless
it's active.
Florian: This could work when the space is 0 and you could reserve
that on both sides. Even when it's 0 it visually takes
space.
Rossen: They only get rendered...in layout they only have render
size while you're manipulating the content...while you're
scrolling. So it's visible when you have a pointer down.
The rest of the time they're not visible.
Rossen: But why would you mess up layout for the rest of the time?
<fantasai> + MAY make it invisible or semitransparent at other
times
Florian: You don't mess up the layout, you always reserve.
Rossen: I get your point. You want to reserve the space on both
sides so when the scrollbar is visible it's not overlaying
any of the content. My pushback is for overlay scrollbars
they're only visible when you're scrolling and when you're
scrolling your not reading
TabAtkins: That's why I said a second value is to merge with
overlay where it can go to 0 if your platform uses
overlay. So that way you have one that's always
consistent and one that takes up as much space as it
can, but it's predictable so that when scrollbars show
up it won't jiggle.
Rossen: I got your point. For layout...for scrollbars that do take
up layout space this feature makes sense.
* fantasai thinks this needs to be written up
TabAtkins: I think the first is important; I know a requested use
case is for authors to turn on overlay and then reserve
the space so that no content is ever covered. So making
that easy seems worthwhile.
TabAtkins: We can bikeshed over the names to make sure it's clear
and they point you in the right direction. But I feel
strongly from the use cases I've seen we want both.
Rossen: I suggest that instead of a unit we look into something
like gutters that we can do by box. Because people will
start depending on this.
astearns: There's lots of details. We're over time. People want to
work on this to allow control of layout, but not
scrollbar.
Florian: There's two points against the proposal. Overlay needs to
change definition which I can do. Second is what we were
just talking about.
astearns: I think we should continue discussion in the issue. You
can propose changes there. We're a bit overtime now.
astearns: Thanks everyone. We're done.
<liam> padding-left: max(1em, --ui-scrollbar-width)
<TabAtkins> liam: My plan is to push for either a `scrollbar`
keyword, or better, a `scrollbar` <length> unit.
<liam> sounds good
* Bert thinks liam may have an interesting way out
<jensimmons> yes, let’s not get into giving people the ability to
‘style’ the scrollbars. People want that. People used
Flash just to get that. It was a usability nightmare.
<TabAtkins> liam: Assuming we get a max(), yeah, like
`max(1em, 1scrollbar)` or something.
<astearns> liam - please add a comment to the issue
<liam> of course, there's likely a user preference or locale
setting for whether scrollbars are on left right, top or
bottom
<liam> ok
Received on Thursday, 11 August 2016 01:36:08 UTC