- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Sep 2018 19:59:18 -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 Text 3
----------
- Since word-wrap:break-word cannot affect min-content due to web
compat there is now a need to achieve that behavior through
another method. Discussion is ongoing in github #2682 to
determine the best approach and anyone interested is encouraged
to participate.
February F2F
------------
- Location is still unknown for the February F2F but there is work
in progress to produce alternate locations.
Selectors
---------
- RESOLVED: Add :blank for input selectors (Issue #1283)
- RESOLVED: :empty does cover white space (Issue #1967)
Scoping
-------
- RESOLVED: Specificity of :host() is 1 pseudoclass + specificity of
argument. (Not just specificity of argument.) (Issue
#1915)
CSS Text 4
----------
- RESOLVED: Accept the proposal from fantasai and Kobayashi-sensei [
keep the full size of the larger glyph and trim smaller]
(Issue #1668)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0018.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brian Kardell
Chris Lilley
Nigel Megitt
Thierry Michel
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Sean Voisen
Greg Whitworth
Regrets:
Tantek Çelik
Peter Linss
Stephen McGruer
Manuel Rego Casasnovas
Jeff Xu
Scribe: dael
Agenda Setting
==============
Rossen: Reminder to book TPAC travel if you haven't already. Airfare
is going up, hotel availability is going down.
Rossen: Let's get started
Rossen: As usual I wanted to see if there are additional agenda
items.
florian: Did you see my email?
Rossen: I did not. Let me see.
[email hunting]
[email:
There's been two more issues marked Agenda+ since you compiled
this list, and since the agenda is quite light, maybe we can
take them on as well:
5. [css-values] Define <'property-name'> notation to exclude
listification https://github.com/w3c/csswg-drafts/issues/3146
6. [css-text-4] text-transform: full-size-kana
https://github.com/w3c/csswg-drafts/issues/3143
]
Rossen: Sure. We can try. Thank you. Anything else?
Rossen: Is TabAtkins on?
Rossen: I wanted to see if there was Feb F2F updates.
Rossen: Perhaps someone can ask him or he'll see the minutes since
he's not on
CSS Text 3
==========
word-wrap/overflow-wrap: break-word should affect min-content
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2682#issuecomment-421705575
fantasai: Summary: we discussed making word-wrap:break-word affect
min-content since that's desired. Mozilla implemented and
found it not web compat. We reverted changes and re-opened.
fantasai: What do we want to do to solve this use case.
fantasai: I don't think we have a concrete proposal. There have been
comments. One option is tie this to word-break:break-word
which is impl by webkit and has that behavior. Another is
add a different value to overflow-wrap property
fantasai: Another is to have a property that sets the min content
size explicitly, dbaron has proposed that in the past.
fantasai: Those are options discussed. I don't have a clear idea of
what I think is best. Wanted to bring up.
florian: Obvious thing to do is standardize what webkit shipped, but
that value doesn't make sense on the property where it was
added. That's weird and confusing so we're looking for
alternatives.
Rossen: Any other opinions?
Rossen: Should we perhaps put this back for discussion on github and
once there's a concrete proposal we can try to resolve?
Preference?
fantasai: I'm happy to take back to github but I wanted to make sure
this is on people's radar. I want to resolve, but not
right now since there isn't a clear path.
Rossen: So move back to github and encourage discussion?
fantasai: Yeah.
Rossen: Thanks.
February F2F
============
TabAtkins: After getting approval from my manager and looking into
hotels I got word from higher management that Hawaii
isn't best to go because there's a policy to host in
Google places
TabAtkins: Alternates: Google Malaysia and Google Singapore. Do
either sound good?
leaverou: Nice but further.
<astearns> +1 to either
dbaron: From bay area they're further then Australia
florian: For me closer
fantasai: Google LA or something? In terms of getting people there
that's less painful flights
jensimmons: Want to vote for something that's not such a long haul.
No events in north America is hard.
TabAtkins: We have LA and that's fine.
florian: I have 3 meetings in north America between Jan and June so
not really looking for another but maybe that's me.
TabAtkins: Hawaii was equidistant, but we don't have an office there
so we have to go with one side.
fantasai: Japan or SF/LA is one long flight rather than 2.
Rossen: San Diego?
TabAtkins: I don't think so but I'm not sure.
Rossen: That was great when plinss hosted.
florian: Should I try for Kyoto? Or would people rather another
season?
Rossen: TPAC next year already.
chris: Prefer to avoid because I've already got multiple meetings
there.
fantasai: I suggest west coast US then. I think putting a lot of
people on back to back long haul isn't great for F2F. When
we had a lot of people in Sydney it made sense, but now we
don't have anyone so maybe not a general policy.
florian: If it's just me, whatever
fantasai: If you want east Asia, Taipei or Seoul
TabAtkins: We rejected Seoul due to mid-winter
<gsnedders> I suppose also Vancouver if we're still mildly trying to
avoid the US? There's a Google office there, no? Though
I have no idea of size.
dbaron: I'd prefer Japan twice over Singapore or Malaysia. Between
Singapore and Malaysia, Singapore is easier to get to right
now due to competition in SFO-SIN flights. But it's an 18h
flight from SFO
Rossen: We have, from what I hear, Singapore, perhaps Japan though
that's 2x in one year, West Coast US
TabAtkins: San Diego probably doesn't have meeting space for us
Rossen: More space in LA?
TabAtkins: Looking.
Rossen: Or we head to Europe again but that's twice Europe.
florian: I'm loudest complaint on west coast and Europe doesn't help.
Rossen: TabAtkins thank you for the update and we appreciate the
effort. Let's end here and once you have an idea of the
possibilities for locations of west coast or Singapore we
can come back next week or over mail.
Rossen: Thank you.
<jensimmons> I definitely prefer west coast of North America. Let’s
pick a major hub city for international flights — like
Vancouver or LA. We also have a lot of office space
available in San Fran, Mountain View…. lots of options.
<TabAtkins> Okay, LA is out too. It's got setups for *much larger*
meetings, and *slightly smaller* meetings (16-18), but
nothing in our sweet spot.
Selectors
=========
decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
fantasai: There's a related issue to decide first.
Add selector for blank inputs
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1283
fantasai: Adding a selector for blank input fields
fantasai: If we want to do that blank is the best name. If we do
that we can't use blank for meaning empty.
fantasai: Comments, thoughts?
fantasai: We can reserve the name and not resolve to add or decide
we don't want to do this.
dauwhe: Also have blank selector in pages
<bkardell> :blank seems right for inputs to me
fantasai: Yeah. That's a different scope so not a naming conflict
Rossen: Opinions?
fantasai: Options:
<fantasai> a) Decide to add :blank for input selectors
<fantasai> b) Decide to reserve :blank but not resolve to add yet
<fantasai> c) Decide we either don't care about blank inputs or
don't want :blank for them regardless
fantasai: We should decide on a/b/c and then go back
<bkardell> my opinion is above -- a)
Rossen: This was 1283, right?
fantasai: Yeah
Rossen: I see one opinion
fremy: I just looked and I like using a function on empty and
specify if whitepsace is a parameter.
fantasai: That's issue 1967
dbaron: One proposal in the past is have an attribute selector like
syntax that you can use with form control. A way to put form
value into attribute selector syntax.
fantasai: Would it handle all the relevant use cases?
dbaron: White space variations on empty string? Or does that not
matter as much?
<dbaron> e.g., input[:value=""]
<bkardell> i would think it would matter for input
fantasai: Don't know. If we go with functional notation for empty we
might want same here.
Rossen: We can add 'ish' param ^-^
Rossen: Back to original options, can we narrow those down?
fantasai: I suggest a or b which means not use :blank in 1967
<bkardell> are we not considering @dbaron's idea
Rossen: 1283 is we're supposed to use blank. That's option a
fantasai: I think for the question of blank inputs we can go with
dbaron option or we can decide to reserve blank or we do
both.
<bkardell> can we say the value is trim'ed in dbaron's?
fantasai: Is blank a thing we would want to apply to inputs or empty
elements that might contain white space
Rossen: Opinions?
nigel: I like the input value idea, it's nicely extensible. If you
need a keyword is an interesting question. You can also
define a regex and have a valid/invalid keyword.
nigel: For input controls, nonvalid and invalid are the obvious
categories as a min. If you need a test for particular
strings is a bit much
<fantasai> nigel, see Chapter 12 in https://www.w3.org/TR/selectors-4/
fantasai: Have required and optional, but we don't have hey is this
input empty or not.
<bkardell> nigel I think part of the question is still whether " "
is the same as "" or null
<nigel> @fantasai - thank you for the pointer!
gregwhitworth: I don't hear strong opposition to blank [missed]
fantasai: Empty wouldn't work on inputs because they're empty
gregwhitworth: I think I lean toward a
nigel: Blank being different from some white space can be considered
to be the same as opposed to empty which can be literally the
null string
gregwhitworth: I don't disagree but I feel we're in a weird world
with empty and invalid. Invalid would hit the regex
pattern I think.
gregwhitworth: Trying to solve a lot of same problems with 3
classes. That's probably why fremy wanted to lean
toward functional. I think we can bikeshed name later
but I don't know anything better.
<fremy> @gregwhitworth: I was thinking about `:empty(value)` for
instance
<bkardell> dbaron's thing sidesteps the naming issue if we can say
the value is trimmed?
Rossen: I agree with gregwhitworth. I would prefer to make more
progress so we can go back to 1967.
Rossen: Objections to "Decide to add :blank for input selectors"
RESOLVED: Add :blank for input selectors
Rossen: nigel to gregwhitworth's point we might come back and
bikeshed
<nigel> I don't follow why we don't use the same definitions for
blank and empty as are in selectors §13.2 and 13.3
decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
fantasai: The discussion was about...one of the problems with empty
selector is it does not select elements with only white
space. Those are fairly common. <li>enter<li> will auto
close and have a line feed and therefore is not empty.
fantasai: Issue was can we have a selector that means actually empty.
fantasai: Last conversation was either add a second selector that
means empty and ignore white space or redefine :empty
where if it contains white space it's still empty
fantasai: Discussion on webcompat, weren't many instances of empty.
Daniel wanted a distinction somehow. Point that
empty-cells ignores whitepsace the same way we proposed to
redefine :empty.
fantasai: After that discussion Brad proposed making empty a
functional pseudo class to have different kinds of empty.
That's where we're at.
Rossen: What's the favored proposal in your PoV?
fantasai: Ideally :empty would look from the author prospective and
ignore whitepsace. If need more options make it a
functional pseudo class
<TabAtkins> I agree that :empty's current definition is just plain
too strict to be worthwhile. I bet we can loosen it by
default, and don't need to make it controllable.
<gregwhitworth> I agree with TabAtkins here. Probably a good default
is not to include white space
bkardell: Definition of :empty is so strict that I feel part of the
ask is to lessen that strictness. I don't know that
getting that wrong will be more helpful.
bkardell: Example if it has a link tag or style tag would an author
consider that empty? What about a hidden attribute?
Comments are a different node type so they don't count.
This raises a lot of questions we should carefully
consider or it'll be similarly disappointing.
bkardell: How close can you come to what people want.
florian: Good idea to consider these things you've listed. Driving
use case is indenting and self-closing tags. Just loosening
to consider white space would pretty much cover the use
case.
bkardell: Lots of comments and articles about editors. Closing is
one, but Daniel brought up last time an editor when you
create something with nothing in it how to style that is
tricky. Other blog posts looking for that. Other blog
posts wanting more.
bkardell: Not sure why we say the use case is that unless we're sure.
<TabAtkins> We can't ignore <style>, unfortunately - you can display
those! (and make them contenteditable, for live-editting
of a stylesheet).
<TabAtkins> But yeah, ignoring white space-only text nodes seems A-OK
florian: Not sure I see the use case for a selector that only
selects link elements.
florian: Why would you want to select these things specifically?
bkardell: Not only things with link. Select something that from
author standpoint thinks is empty. Functionally if you add
something from an editor it may have content, but from the
viewer/author prospective it's empty.
florian: I hear you but don't agree.
<TabAtkins> You can display a <link> too...
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6230
fantasai: A lot of these selectors won't work if you don't
understand your markup. That's true for :nth-child and
:only-child. The structural selectors don't work with
stray elements in the markup. That as a driving use case
doesn't make a lot of sense. If you're in that world you
need to put classes on. You can't use these without
control on markup.
florian: As TabAtkins put in IRC you can display most of what you
wrote.
fantasai: Definitely we can't change :empty to solve that. We can't
make things depend on styling. So where there's tags but
no text if you style that it's very visible. From author
view it does not look empty. It comes down to are you
understanding your markup. If you're not the tree
selectors can't help you. Can't write selectors that work
based on styling of element.
fantasai: If a wysiwyg author thinks the thing is empty depends on
what you see. We can only help authors in markup
bkardell: Yes, I think what a lot of people want is not possible.
Thinking through and making the least surprising thing
seems good.
florian: I wonder about comments. Are they gone before we do
selector parsing?
TabAtkins: They don't show in the dom tree that selectors see
florian: Only white space means white space and comments
TabAtkins: And other nodes
florian: As long as it falls out
bkardell: Empty clearly specifies that
fantasai: If our goal is not surprising [missed]
TabAtkins: Selector modal only sees element and text nodes. Other
elements aren't seen by selectors.
florian: I think we circled around. Can we resolve on :empty also
allowing white space?
fantasai: sgtm
<TabAtkins> +1
Rossen: Proposal is :empty does cover white space?
florian: Yep.
Rossen: Other opinions?
Rossen: Objections to :empty does cover white space?
RESOLVED: :empty does cover white space
bkardell: Wanted to clarify we're changing the existing definition
of :empty?
florian: Yes.
bkardell: Last WG there were concerns about that where someone left
an :empty that was false as a test. No concerns on that?
fantasai: Last discussion I recall Rossen said he checked and didn't
see enough use of :empty. Author mistakes or author
intention it's possible someone put a stray :empty or the
author put :empty and it didn't apply to every element due
to white space. Not sure if this would break more uses or
fix more uses
florian: But it's rarely used anyway
<bkardell> yes, me too, what fantasai said
Rossen: And I just looked at the data since then and I don't see an
uptick of usage. If there are different numbers we can
revisit.
<bkardell> ok, no real objection then
Rossen: Anything else to resolve?
Scoping
=======
Specificity of :host, ::slotted, and :host-context doesn't seem to be
defined?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1915
emilio: We resolved on :host and ::slotted for specificity of inner
selector. Should :host account for own specificity? There's
incompat. Should *:host be same as :host(*)?
Rossen: Does anyone have an opinion?
<fantasai> Question was whether :host(*) should be the same as *:host
emilio: Should specificity of function a host selector be only the
selector or selector+pseudo class for specificity. I think
2nd. That is consistent and increases specificity of the
selector.
TabAtkins: This is inconsistent with :matches, but host on its own
just making a * argument should be 0 makes me lean toward
your argument.
emilio: Works great
Rossen: Other opinions?
fantasai: +1 from me
Rossen: Objections?
<bkardell> that's a new precedent right?
<bkardell> nothing else works like that I think?
<TabAtkins> bkardell: Yeah, new precedent, kinda sorta.
bkardell: It's the only decision that makes sense, but it's new.
Nothing else works this way today.
emilio: Yeah, don't have many pseudo classes with selector arguments.
<bkardell> +1
<bkardell> it makes sense
Rossen: Makes sense as a pattern going forward.
<TabAtkins> I mean, :matches()/:not() mean *absolutely nothing*
absent their selector; there's nothing there otherwise.
:host *does* affirmatively select an element all by
itself, and then the selector narrows it down.
<bkardell> right, I agree tab - you explained it well... I was just
thinking I think that is new and wondering if I was right
about that - it wasn't about objecting or anything
<TabAtkins> Proposed resolution: specificity of :host() is 1
pseudoclass + specificity of argument. (Not just
specificity of argument.)
RESOLVED: Specificity of :host() is 1 pseudoclass + specificity of
argument. (Not just specificity of argument.)
CSS Text 4
==========
text-spacing, closing-opening bracket fullwidth punctuation collapsing
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1668
<fantasai> ] [
fantasai: Earlier version of text spec...this is about combo of
closing full width bracket and opening full width bracket ^
<florian> or ）（ or 」「 etc
fantasai: Typically it takes up a full em but that's too much so
Japanese typesetting cuts that in half. Usually by
deleting white space of second glyph. Not right if they're
different font sizes
fantasai: Kobayashi-sensei says correct behavior is keep space of
larger or trim 1/4 of each. Change we made was incorrect.
We should change to 1/4 of each glyph or always use the
full glyph of larger and cut smaller in half
florian: He said both is acceptable, but keeping larger is preferred.
florian: Impl what do you think? Is it hard to keep the bigger? If
yes we can settle for the good enough.
<bradk> Seems weird that kerning in the font doesn’t handle that on
its own
<florian> bradk, it cannot just be kerning, because that's optional
behavior, and also when on, needs to work across fonts.
fremy: I'm not sure we support this kind of font features across
text nodes. I'm not sure we'd have a path to this
florian: I suspect it's easier to trim half of the smaller one
because we might be able to invoke open type features. If
we do 1/4 of each I don't know open type can do that.
fantasai: I think I agree.
fantasai: If there's no feedback from implementors we propose keep
the full size of the larger glyph and trim smaller.
dbaron: I'm still trying to understand how much action at a distance
there is. How much is that making changes at arbitrary
distance in text.
fantasai: It's the adjacent character. It's two adjacent characters
and you have to trim to reduce amount of space.
dbaron: Just adjacent characters?
florian: Yes. If there's anything, border, linebreak, anything, it
doesn't count.
TabAtkins: Same boundary we use to determine if we can do kerning?
fantasai: Yeah.
florian: Don't think. If you switch fonts I think no kerning, but
this should work.
fremy: I don't think we have something like this right now.
fantasai: I don't think anyone does this as L4
Rossen: From use case PoV it seems this behavior makes most sense. I
don't believe anyone has impl experience so we can make the
call on if this is expensive.
Rossen: What if we try and decide on what makes most sense and when
we get more impl experience we revisit?
fantasai: That's fine. And as florian pointed out there's open type
to help with trimming and they don't 1/4 trim so it's more
consistent
Rossen: Objections to resolving as proposed by fantasai and
Kobayashi-sensei ?
RESOLVED: Accept the proposal from fantasai and Kobayashi-sensei
Rossen: We've got some topics left, but we're at time. Thanks very
much for joining. Book your trip for TPAC if you haven't.
Received on Thursday, 27 September 2018 00:00:28 UTC