- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Dec 2017 06:44:09 -0500
- 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.
=========================================
Overflow
--------
- RESOLVED: Specify the webkit/blink behavior for issue #2006
- hober will get a description of the current behavior to help
dbaron write the spec text.
Color
-----
- RESOLVED: Round in this case (issue #1983)
Selectors
---------
- As a part of the request to rename :blank (issue #1967) fantasai
indicated that another possible solution would be to redefine
:empty to also capture whitespaces.
- There were concerns that changing :empty would cause breakage,
though a preliminary look through Microsoft's data indicated
very low usage.
- In addition, it was stated that there was benefit in have the
controls available with having two different properties instead
of forcing it into one.
- Several people leaned toward keeping two properties instead of
combining, though fantasai wasn't convinced. Glazou and
fantasai will connect later to try and come to an agreement.
- Everyone seemed to believe that if :blank stayed in the spec it
should be renamed.
Background
----------
- glazou brought to the group strong feedback he received from web
authors that 'border' shorthand resetting 'border-image' but not
being able to set it was a mistake.
- In contrast to that feedback, concern was raised that any
reversion would adversely effect those using border-image.
- There was discussion around how used border-image is on the web
but there were several disagreeing viewpoints on usage.
- Discussion will continue on the github issue
(https://github.com/w3c/csswg-drafts/issues/2108 ) to allow for
additional input from a wider group then those on the call.
Device Adaptation/CSSOM View
----------------------------
- RESOLVED: Spec the <meta> viewport in CSSOM View
- Rossen will work with the Microsoft team to identify who will
write a pull request to add <meta> viewport to CSSOM View.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Dec/0032.html
Present:
Rossen Atanassov
David Baron
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Daniel Glazman
Dael Jackson
Brad Kemper
Peter Linss
Thierry Michel
Michael Miller
Anton Prowse
Melanie Richards
Florian Rivoal
Alan Stearns
Eric Willigers
Regrets:
Rachel Andrew
Tab Atkins
Tony Graham
Chris Lilley
Myles Maxfield
Manuel Rego
Jen Simmons
Lea Verou
Greg Whitworth
Scribe: dael
Overflow
========
How should ignoring overflow on the *-start sides of the scrollport
be done?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2006
astearns: It sounded like the idea is change the behavior so that
things on start edges that are not in scrollport do not
contribute to scrollable area.
dbaron: Maybe I should step back. There's a long interop bug where
edge/gecko do one and chrome/webkit do another. I'm assuming
English text in this example.
dbaron: How things to the top or left of a scrollable area get
ignored.
dbaron: Scrollable areas don't let you scroll to top or left.
Interesting is top and right or left and below. In chrome/
webkit those don't contribute to scrollable area. Edge &
Gecko they do.
dbaron: More webcompat is chrome & webkit behavior probably.
Question is if we should spec that behavior or do something
else.
Rossen: Thanks for bringing this up dbaron. This isn't a new topic.
I remember, I think, smfr at the time saying that they do
try and clip as many things as possible out of scrollable
areas that will not be visible. They optimize for less empty
space.
<dbaron> Yeah, I thought I remembered discussing it before, but I
couldn't find minutes...
Rossen: Impl-wise there's quite a bit of inconsistency between
webkit and blink so when we spec this I would expect this to
be kinda precise because if you start using things like
position:relative you'll find that sometimes they will and
sometimes they won't clip so even in their impl there's
inconsistency.
Rossen: I'm all for more interop and better UX, but I want to spec
something that will be more concrete in terms of which
bounds get clipped and how. Otherwise I support this.
Rossen: Do we have someone from WK or Blink?
hober: I just joined and don't know topic
astearns: [summarizes]
astearns: Sounds like rough consensus on spec WebKit/Blink behavior
as long as we come up with a consistent way of describing.
Rossen: Yeah, that's my only feedback that when we spec we should be
explicit on what bounds we consider when compute scrollable
bounds. So things like are we considering visible bounds,
things offset by relpos, transforms, so forth and so forth.
astearns: Objections to spec blink/webkit behavior for this issue?
RESOLVED: Specify the webkit/blink behavior for issue #2006
astearns: dbaron will you make the overflow spec edits?
dbaron: It's a little ways out in terms of figuring out behavior
first.
astearns: It would be nice to have blink/wk contribution to help
spec the behavior.
hober: I can take an action to drum up a desc.
ACTION hober get a description of the behavior for issue #2006
<trackbot> Created ACTION-866
Color
=====
Spec doesn't specify whether implementation must honor <decimal> in
rgb/rgba or if it can truncate to an <integer>
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1983
astearns: Looked to me like discussion got to the point of saying
rounding is correct behavior.
astearns: Does anyone have a comment?
astearns: Anyone think we should postpone? Or resolve on rounding?
<glazou> +1 for rounding
fantasai: Chris wants rounding so presumably he'd be happy with that
resolution.
astearns: Obj to resolve rounding for this issue?
RESOLVED: Round in this case (issue #1983)
Selectors
=========
Decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
fantasai: We had an issue in the spec for name of :blank. It was a
request to pick a name. There was a discussion in the past
to redefine empty to allow whitepsace inside it.
fantasai: That's a question for the WG. Question is do we want to
drop :blank and have :empty allow for whitespace or do we
want two descriptors? In the second case we need a name
for the selector.
Rossen: Use case?
fantasai: Most of the time you're trying to pick something empty
there's often white space in there. Currently if you try
and select empty table cells but you didn't carefully
close all tags an make sure there were no spaces then
:empty doesn't work.
glazou: Another reason they're not completely empty is because if
there's no content you don't have a frame to render and then
cannot edit.
fantasai: There should be a frame
glazou: Not always.
glazou: It means we have tons of doc in the wild with whitespaces.
<AmeliaBR> I liked :blank. But if we need to be more clear,
:whitespace-only is as explicit as we can get.
<fantasai> AmeliaBR, it might not contain any though :)
fantasai: Question is about the selector. We have :empty. We can say
it also matches elements that contain whitespace. Or we
can say it does not match when it has a whitespace in
which case we need another selector that matches to things
with nothing or white space.
glazou: I favor the latter.
dbaron: I think :empty has been around long enough that we would
break if we changed the behavior.
florian: On the one hand I have a hard time thinking of use case to
distinguish, but there is a compat concern and that's what
should decide the issue.
<AmeliaBR> (Definitely don't change the current behavior of :empty.
That could mess up use cases like using it to show a
placeholder for a <div contenteditable>
astearns: Might be somewhat difficult to figure out web compat
problems because it's likely code that is dealing with
interaction.
glazou: Has MS commented?
Rossen: I'm interested to find out what the webcompat is. I don't
remember if we even impl :empty. I'd be surprised if there's
too much interop.
glazou: I was asking about the stats MS has online on properties.
Does it include selectors? Do we have metrics?
glazou: On :empty usage
* bradk assumes redefining :empty would break things, but we do need
something like :blank
Rossen: I'll take a look at what the crawlers have seen. I'd be
surprised if it's wildly used.
glazou: Me too.
* fantasai would be surprised if it does break anything: how many
people are relying on it to *not* select an element that
contains whitespace?
astearns: Whether or not it's possible to redefine :empty is there a
reason to have both?
Rossen: I'd be in favor of the simple way to only have :empty that
fantasai described.
astearns: Shall we leave the issue as needs data?
fantasai: Yes
Rossen: Looking at CSS usage I don't see hits for :empty. fwiw
there's nothing we find.
glazou: So nothing prevents us from redefining it?
Rossen: That's my read. If anyone has data for the contrary I'm
willing to take a look. On our end I don't see anything.
fantasai: To be clear the case that would break is if someone uses
:empty and expects it not to select an element that
includes only whitespace.
Rossen: That sounds to me like a fringe case. This could be a
tool-ability work around where an editor is carefully adding
and removing and this is selecting only things not edited by
a user yet. But this is an edge case. I'd say we should make
the change.
glazou: Case where element is contenteditable and you want to make
difference between entirely empty and whitespace is there.
dbaron: [missed] someone tried to use :empty, it didn't work, they
didn't remove it and then it suddenly matches.
Rossen: If we find those use cases let's discuss, but I don't see
any usage.
<AmeliaBR> Example of the contenteditable usecase, would be weird if
it treated a space as empty:
https://codepen.io/AmeliaBR/pen/QvMGmR?q=%3Aempty&limit=mine
astearns: Proposal is redefine :empty to allow whitespace and to
remove :blank
astearns: Objections?
glazou: I don't like it. I'd prefer preserve :empty and have a
selector for both.
florian: You think there's a case for one or the other?
glazou: Then you can write a more complex selector.
astearns: I thought you argued before where when you want a blank
thing...
glazou: I was misunderstood. I want the two features to be able to
handle separately.
fantasai: The case where you only care about non-whitespace is the
more common.
dbaron: This doesn't feel like the kind of thing where we want to
spend a lot of resources on testing for compat. Breaking
changes are a lot of work.
astearns: From the principle of less work, proposal is keep current
definition of :empty and keep current definition of :blank
and have people impl :blank if the empty with whitespace
use case is useful.
dauwhe: Is there concern we have a blank pseudo class in pages?
astearns: Same syntax?
dauwhe: In a page context, but it's :blank. I think in an @rule
astearns: Does that @rule select paes with only whitespace?
dauwhe: Pages created by rendering engine that don't have content.
<fantasai> https://www.w3.org/TR/css-page/#blank-pseudo
florian: So it matches :empty not :blank
dauwhe: Yeah, although you can make master pages with content that
match :blank
dauwhe: Probably not confusing for most, but worth mentioning
astearns: So an argument to change :blank name to :whitespace-only
or something
astearns: First, would anyone object to keeping :empty with current
definition and having a selector that means empty or
whitespace.
florian: Not an objection, but I'm not sure keep things the way it
is is really less work. People need to impl a new thing.
dbaron: But if we change empty people impl the new thing too.
astearns: Work we're avoiding is the web compat check.
Rossen: My position is if we're keeping :empty let's keep as-is. If
we're changing lets do so completely and have something
that's the superset. If we don't care about webcompat let's
not. But if we keep :empty as is 'd oppose to change empty
and have a selector that means something kinda like :empty
astearns: Yeah, I don't think that's on the table.
Rossen: The last proposal I heard was change :empty
florian: No, fix empty to mean what blank means or get both.
fantasai: We have an empty cells property for tables that behaves
like :blank. It triggers when there's white space. So
there's a conflict in meaning.
<fantasai> https://www.w3.org/TR/CSS2/tables.html#empty-cells
fantasai: I wouldn't object to keeping things the way they are, but
I would be annoyed because I've found the way :empty was
defined to be annoying.
astearns: Two avenues and there are people that would obj or be
unhappy with both.
Rossen: Do we go back to GH and see if we can argue more there?
fantasai: I'd like to talk with glazou more offline on his concerns.
astearns: Was there previous discussion on redefine empty?
fantasai: Yes, but nothing formal. When it was first defined I
believe it was discussed and people were saying if there's
a text node in the dom it's not empty, but that's not how
people go about styling their pages.
astearns: I think we've had enough on the call. fantasai and glazou
can discuss and summarize on GH.
dbaron: One other point is elements like :pre where whitespace is
significant.
Backgrounds
===========
Shorthands resetting properties they cannot set
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2108
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html
<fantasai> fwiw, I agree with fremy/Florian/AmeliaBr's comments on
the www-style thread.
glazou: With the introduction of border-image and border resetting
it but not setting it I started getting feedback from
unhappy users where when the set the default border they
don't get the border shorthand anymore. Even after I
explained they don't accept it.
glazou: I got aggressive feedback that the web is about border and
no one cares about border image. Beyond the tone, they have
a point. We changed something that worked in one way for
many years and it does impact how people edit the stylesheet.
glazou: border-image usage is almost 0. The designers that pinged me
replied almost always no we don't use it.
glazou: It's a steamroller to kill a fly.
glazou: In the case of border I think we made a mistake. The
argument about :blank was don't change things for web compat
and here we changed a thing without caring about compat and
we have a problem.
florian: What I'm struggling to understand...if we take into account
the few people that use border-image it does make sense. Is
the argument that we should remove border-image? I don't
think you're saying that. But if we don't I feel like the
behavior for people who do use it is something we need to
care about. Both situations are bad. I don't want to
disagree but I feel alternative is worse.
glazou: Let's talk stats. border is on 99% of website, but
border-image is 0.0something % and mostly with initial
value. I think numbers should favor 99%
florian: But within 99% it's a smaller group. It's those who
manipulate in a certain way.
glazou: We're breaking habits of people writing the technology. They
have the habit of being able to define 4 borders and get the
shorthand. It's not happening anymore. We're breaking the
way they work.
florian: Not 99%. Not everyone uses graphical editors.
glazou: I agree, but anyone who manipulates OM gets a border-image.
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/?q=border-image
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/border-image-repeat/
<Rossen> I suggest looking at the data a bit more before making the
call
<AmeliaBR> Has anyone made a list of other shorthands that have
similar behavior? Font is one (with respect to new
font-variant properties), but I think it should be
possible to allow the full font-variant options to be
specified without breaking anything.
dbaron: Back when we changed border-image syntax and I'm guessing
like in 2012 we had significant compat problems. That was 5
years ago. There's real usage and I don't see how we change
this without causing as much problems today.
<dbaron> my post from 2012, which I had to cite a lot in response to
compat problems, was https://dbaron.org/log/20120612-border-image
Rossen: Quick scan of border-image-repeat is used 63% with things
like youtube, mdn. I wouldn't say border-image isn't used.
glazou: But border-image-source is almost unused.
glazou: I'm proposing to stop resetting border-image with border
shorthand
fantasai: Alternative. Issue is we have border-this-rule then we use
border-top: blue, why do we have to split it out? It seems
like a lot of writing that doesn't need to happen.
florian: Through graphical tools people click on each border
separately and expect that to synthesize into shorthand.
florian: It's valid, I don't buy it's dominant.
Rossen: In this use case I set only top border I do using the short
hand? That makes no sense.
glazou: No, when you just do border top you use border-top. But when
you want to do top/left/bottom/right you want to use the
border shorthand.
<fantasai> border: thin solid red + border-top: solid blue doesn't
need to split everything into longhands. It can just be
serialized out as 'border: thin solid red; border-top:
solid blue'
Rossen: There's one way to represent things during editing and
represent fidelity of what's been changed. There is a
different case of what do you do when you export the final
style sheet that you have serialized based on what the user
did.
Rossen: If we're talking about the export and you want to re-import
it and change it, because you export shorthands as much as
possible, which is great, but if this is the motivational
example where you have to round trip the shorthand, that is
a stretch.
glazou: Motivation for change, there are quite a few projects
embedding chrome or moz. to do specific positioning editors.
All will hit this issue and all will need to impl a hack
because this is not what web designers expect. We have
messages from web designers and we're not listening.
glazou: We did this alone and did this at a time without wed
designer feedback. Now we have it and we're not listening.
glazou: It strikes me that we're trying to gather web designer
feedback at conferences, but here we have feedback and we're
not listening.
fantasai: Feedback of outputting these longhands is reasonable. You
should output something closer to how a hand user would do
it.
glazou: This is not true. We changed a 21 year old behavior.
fantasai: It's been like that for a while. borders and backgrounds
and border-image have been like that since we went to CR.
glazou: And people are seeing it only now. And people are really
upset. They do not accept the explanations. It's the first
time I got insults.
glazou: Do what you want but we cannot ask for feedback, get
aggressive feedback, and say wellll
fantasai: It's not just border-image. There will be additional
things and they'll get output too.
glazou: We have a chance between resetting or putting a warning in
the spec saying you should make sure you put out the right
thing. Web designers thought second was better.
<fantasai> http://glazman.org/tmp/border-shorthand.html shows the
addition of a simple rule blows up the shorthand. Whether
border-image is part of that blow-up or not, it still
blows up.
<fantasai> The solution isn't to change what's reset, it's to not
blow up the shorthand.
<fantasai> Changing the output of that case to #a { border-color:
blue red red; border-style: solid; border-width: thin;
-moz-border-top-colors: none;
-moz-border-left-colors: none;
-moz-border-bottom-colors: none;
-moz-border-right-colors: none; }
<fantasai> isn't going to make it better.
Rossen: Can I propose something? First, thank you for bringing this
and being on the front of taking the heat. Sounds like this
issue will become fairly lively on GH. I think the intro of
the problem has been clearly stated. What if we discuss
further on GH and try and get a broader WG audience after
the holiday.
Rossen: I don't think anyone is trying to say shut up we won't
change or we won't listen because we decided in a vacuum.
I'm personally trying to think through actual use cases. If
you give us a chance to read more and discuss perhaps we'll
get close to consensus.
glazou: Best us case case click on each of the four borders and you
expect border shorthand to appear. I'll put that on GH.
Rossen: This sounds like a great use case.
astearns: So we'll continue discussing this on GH. glazou please ask
people to comment on GH and not www-style.
Device Adaptation
=================
Should Device Adaptation include a normative definition of <meta>
viewport?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/331
florian: The spec has a description of <meta> described in terms of
the rest of the spec. People want a normative definition.
Problem is the rest of the spec is not getting adoption. Do
we expect that to be fixed or do we think this spec will
die because it has some issues and gets pushback. If we
think it'll never be adopted defining <meta> in terms of it
is not useful.
florian: That's the question.
dbaron: One way to look at this is if you suppose there is a spec
for <meta> viewport and then you propose @viewport that spec
would have to define how <meta> viewport works on top of it.
You can look at one possible answer is you should do both.
Device adaptation should define it in terms of how it works
that's compat with the existing unwritten and that should be
written.
florian: Device adaptation was supposed to be written that way.
dbaron: And that's one theory of how things could work.
florian: So if we go by that it says there should be another spec
and then device adaptation should continue existing as-is.
If we start from now rather then the past?
dbaron: Pretty much, I think.
florian: I think I can buy that.
florian: Who should write that? It's about layout so maybe CSS, but
it's <meta> HTML so perhaps HTML. Which WG should own this.
florian: If it's us CSSOM View was suggested. Is it?
astearns: CSSOM View doesn't have a current editor.
astearns: There was a suggestion about an incubation doc.
florian: Incubation is supposed to be things we're not sure about.
Spec needs to be written properly, but there's no wonder if
people will buy into the idea.
astearns: I don't know how much there is about <meta> viewport.
Could it stand in its own module? Or better in CSSOM View?
florian: Mostly a who will edit question. If it's same person as
CSSOM VIew easier together. If not, separate.
astearns: Rossen it's an Edge person who brought this up. Could they
edit it into CSSOM VIew?
Rossen: Sure, we can edit it in. I'll talk to MaRakow or fremy.
astearns: Obj to having this definition edited into CSSOM View?
florian: I don't know if we need to resolve on spec if we find a
person who wants to do it they can pick where it should go,
cssom or separate.
Rossen: The people I mentioned won't take over cssom, but they can
do a PR. I didn't intend to indicate they would take cssom
view
astearns: And a PR might be less work then spinning up a new module.
<bradk> Why not just add the meta spec to the device adaptation spec?
astearns: bradk asked [reads] it is in the device adaptation spec.
astearns: I guess the suggestion is just have the normative
definition there.
florian: Google pushed back saying they don't want the entire spec
to exist so putting things in there looks like an
invitation to gut the rest and leave only that which brings
us back to what dbaron suggested where they can co-exist.
astearns: I think there's value in separating. It makes sense to put
it in CSSOM view. That specs known things.
astearns: This fits in that bucket.
<bradk> I don’t object
RESOLVED: Spec the <meta> viewport in CSSOM View
astearns: Thanks everyone. We are not meeting next week, we will
meet Jan 3rd.
astearns: Have a good break!
<bradk> Happy holidays!
Rossen: One more thing, I want to thank the WG for the very
productive 2017. We did quite a bit of work and a whole
bunch of specs are getting ready to REC and I'm looking
forward to 2018. Thank you everyone for a super awesome year
and happy holidays.
florian: Thanks for awesome chairing.
Received on Thursday, 21 December 2017 11:45:07 UTC