- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jan 2018 20:12:52 -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.
=========================================
Berlin F2F
----------
- Details on hotel accommodations and TYPO attendance were confirmed.
- TYPO has a 45 minute slot for a presentation from the CSSWG. Who
will speak and on what topic will be decided over the mailing
list.
CSS Fonts
---------
- More data is needed to determine if browsers have already
converged on interop for issue #1835 (Handle language/family
dependent cascading of keyword font-size values). dbaron will
reach out to Manishearth to see if he has any tests from when he
implemented the feature.
- RESOLVED: Take Chris's language in
https://github.com/w3c/csswg-drafts/issues/1736
into the spec as an example.
- RESOLVED: Add 1.2-1.5 as the conventional ratio range for the
relative sizes when they're not modifying an absolute
keyword size. (Issue #1711)
- RESOLVED: Serialization when font properties when system fonts are
used moved to L4 of Fonts (Issue #1586)
- Issue #1267 (Default feature list should not require a list of
features to turn on) needs some additional testing on different
platforms (especially iOS and Android) as well as clarification
as to the desired change.
- RESOLVED: Move the issue in https://github.com/w3c/csswg-drafts/issues/1104
(what value is invalid for font-language-override) to
Fonts L4.
- Issue #1000 (Grammar of <feature-value-name>) needs more clarity
as to if it is just an editorial change or a functional issue.
CSS Overflow
------------
- RESOLVED: Add the writing direction dependent overflow values into
CSS Overflow 3
CSS Box Model
-------------
- RESOLVED: Spec this (Allow the texts in input element to be
painted into the top and bottom padding area) in CSS
UI 4.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0021.html
Present:
Rachel Andrew
Rossen Atanassov
Tantek Çelik
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Vladimir Levantovsky
Chris Lilley
Peter Linss
Anton Prowse
Liam Quin
Manuel Rego Casasnovas
François Remy
Melanie Richards
Jen Simmons
Alan Stearns
Greg Whitworth
Eric Willigers
Regrets:
Dave Cramer
Michael Miller
Florian Rivoal
Lea Verou
Scribe: dael
Berlin F2F
==========
Vlad: The follow-up, I sent an email yesterday with procedure
updates.
Vlad: Typo organizers set up a special code for CSS members so it's
a guest ticket for anyone in the group.
astearns: Vlad you may want to just send the code to the private
list.
Vlad: For all of us that's a welcome invitation. So if you're on the
verge as to if you want to attend, expense is not an issue.
Vlad: Related to hotel block, that didn't materialize. Since there
was no clear number from the organizers the hotel wanted an
advance reservation rate and so they decided to have people
take care of their own reservations.
Vlad: Rooms are available. Rates from the block rooms were same as
is online so you may as well book individually.
Vlad: Third thing, there's a speakers slot on Apr 13 for 45 minutes
reserved for the CSSWG. It can be 1 person, 2 or 3 people to
cover multiple subjects. They're looking forward to learning
something.
Vlad: Compared to last year where there was a specific focus for all
speakers, this year it's much more open. I mentioned subject
options in the email, but if you think there's a topic of
general interest please suggest.
Vlad: We have a reserved time slot.
Rossen: And that was Friday?
Vlad: Friday am 45 min slot
<tantek> can that be added to the wiki?
Rossen: I'd suggest to coop on the mailing list and figure out who
is willing and possible topics.
<Vlad> https://www.typotalks.com/labs/
Vlad: Yep. I'll put a link to the typo labs ^
Vlad: Topics aren't limited this year to anything specific. I asked
organizers if they had a preference for the presentation, but
I haven't heard back and I think they would be open to our
suggestions.
astearns: So please do volunteer for talks. If we don't get
volunteers, Rossen and I will volunteer people.
CSS Fonts
=========
Chris: Is myles on?
Chris: I did see comments from dbaron which were helpful. Is he on?
dbaron: I'm here.
astearns: No myles. Let's see what we can get through. We can ping
him with resolutions.
Handle language/family dependent cascading of keyword font-size values
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1835
* fantasai agrees with dbaron on this issue
Chris: First one is issue 1835 which is language and family
dependent cascading. Spec is vague. Comment that for web
compat UA have converged somewhat and should spec say
something? myles says no to let browsers compete. dbaron said
there is web compat and spec shouldn't pretend it could be
anything.
Chris: Sounds reasonable, but it means you need actual spec wording.
Possible list of values. I'm not sure what each browser does.
dbaron: I feel like it's awkward to agree without myles.
astearns: If we're unclear on what browsers do we need data.
astearns: Perhaps the data will tell us if it's possible to describe
or not.
Chris: That's reasonable.
dbaron: I think Manishearth did a bunch of that while impl in stylo/
servo. I don't know how well he remembers since it was a
while ago.
astearns: His comment was browsers seem to have similar behavior.
Chris: Based on testing or a feeling?
dbaron: I think he wrote a bunch of test cases. Don't know if
they're in a standard format
Chris: Would be useful to see.
dbaron: I don't know if he still has it.
Chris: Absolutely. Anything would be very helpful. Will you ask him?
If you say he doesn't have anything then okay, but it's worth
checking.
dbaron: I can ask him in the GH issue.
Chris: Yes, okay. It's unfortunate we don't have Myles. My goal is
round up the DoC so we can finish CR.
Do generic fonts resolve to a single font face value?
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1736
Chris: AmeliaBR suggested wording. I modified that based on myles'
comments. Seemed generally liked, but myles wanted it not to
be an exclusive list. Seems okay to me. dbaron commented
recently.
dbaron: Yeah. I think if we're going to say it's okay to choose a
different font for same unicode code point in same language
with same font we should have an idea of why we want to do
that.
Chris: Yes.
dbaron: And user preference didn't seem to be a great description of
the reasons.
Chris: To me it seemed more likely an impl may want to avoid ransom
note effects or to avoid font family switches.
Chris: How should we proceed? Text I proposed has been there since
Sept 2017. No one has said they didn't like. There were 2
lgtm from AmeliaBR and Myles.
astearns: Looks good comments only had the one caveat that they
would like it to be "for example"
astearns: And dbaron are you okay with the existence of this as is
or do you want more motivation?
dbaron: If it is flexible I'd rather it not be tied to that list so
I guess for example is okay. That makes it more flexible. I
don't have strong feelings here. I'm not crazy about
flexibility but if is flexible for example is better.
Chris: And it's allowing generic to be made from composites.
dbaron: But that would be allowed without the variants in there.
That's the result of code point.
Chris: I think taking it back to initial comment that does resolve
that Latin and Japanese aren't expected to be the same.
Chris: I propose that I put the modified language in the spec and we
see if there's anything left to do.
[Proposed language:
All five generic font families must always result in at least
one matched font face, for all CSS implementations. However, the
generics may be composite faces (with different typefaces based
on the Unicode range of the character, the language of the
containing element, user preferences and system settings). They
are also not guaranteed to always be different from each other.
]
astearns: sgtm. Objections to putting this parenthetical as a for
example into the spec?
RESOLVED: Take Chris's language in
https://github.com/w3c/csswg-drafts/issues/1736
into the spec as an example
Make larger/smaller simple ratios
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1711
Chris: myles said he tested this and on 3 browsers they agreed on
absolute font size but not relative. dbaron you commented you
think the content in practice depends on ratios. If we allow
free choice the content wouldn't be web compat.
Chris: Do you have specific language you want to see?
dbaron: I think what I'm saying is I'm in favor of Manish's original
proposal, but I would spec the ratio
Chris: Is the ratio doc?
dbaron: I don't know.
Chris: He's also saying existing spec has complex table and no one
does that.
Chris: Should we remove that? Mark at risk?
dbaron: I'd be in favor of removing the table.
dbaron: The link doesn't work.
Chris: I'll have a look.
Chris: See what's happened. It hasn't disappeared since Aug I don't
think. Spec hasn't changed much.
<Rossen> https://drafts.csswg.org/css-fonts-3/#font-size-adjust-prop
<astearns> https://drafts.csswg.org/css-fonts-3/#typedef-absolute-size
astearns: Is it the table below ^?
astearns: It's not in that definition but it's below. There are 2
absolute-size anchors.
astearns: The idea is that since nobody is using info in table we
remove it?
Chris: Right.
dbaron: I'm not sure it was this table. It's about the absolute
keywords rather then larger and smaller.
Chris: Yes.
Chris: Also that just says guidelines so there's nothing to conform
to.
Chris: It says UA is free to interpolate or round to the closest.
Seems to say relative sizes are relative to the absolute size
table.
astearns: I think I've confused myself.
astearns: We are just talking about the larger and smaller keywords
and what they do?
Chris: Right.
astearns: Okay.
Chris: Spec says you go up or down a size in the table and you read
what that computes to.
dbaron: The issue is with the prose in the definition that refers to
the table, but not the table itself.
Chris: Right.
astearns: So myles was saying make the spec more general, but I
don't see how we could because definition says UA is free
to do whatever it wants.
dbaron: Though I think if everyone does 1.2 then maybe we shouldn't
say it's free.
Chris: We went from 1.5 to 1.2 and we've pushed 1.2 strongly for
quite some time.
Chris: Maybe spec says 1.2 is convention? There needs to be guidance
for the mythical new implementor.
dbaron: I believe Gecko treats larger and smaller as factors of 1.2
That may be pretty interop but I don't remember for sure.
astearns: What about adding 1.2 as a conventional ratio but not
requiring.
Chris: Works for me.
astearns: dbaron is that enough for you?
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1361550 is
where Gecko changed to use 1.2 as a ratio
dbaron: Fine for me. I linked to the bug when Gecko changed the
behavior, but I haven't read it. It says Chrome and Safari
use 1.2 and 0.85.
dbaron: In Gecko we used 1.2 and 1/1.2 which isn't exactly the same.
astearns: Objections to adding 1.2 as the conventional ratio for the
relative sizes when they're not modifying an absolute
keyword size?
Rossen: Looks like we're 1.5. I don't believe I've seen interop bugs
on this.
Rossen: If anything I would reserve the right to come back next week
and ask for a change, but I don't object.
Chris: If someone says larger and smaller they don't much care. In
practice I don't think they're much used.
dbaron: Agreed people don't use, partly because no interop
Rossen: We're currently using 1.5. Yep. Reading through both larger
and smaller we're consistent on 1.5x
Chris: That's what CSS1 said, then we changed it in like '98.
Rossen: And that's likely the last time we changed this code.
<gregwhitworth> smaller = 1.6% usage | larger .47% usage
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/font-size/
astearns: We could do a guidance ratio range where browsers in
practice tend to use 1.2-1.5
Rossen: I'd be happy with that.
astearns: Obj to a ratio range?
RESOLVED: Add 1.2-1.5 as the conventional ratio range for the
relative sizes when they're not modifying an absolute
keyword size.
Chris: I don't understand gregwhitworth's IRC which implied 1.6
astearns: That's usage.
astearns: 1.6% of sites use smaller...that's high.
<aja> smaller in UA sheets for <small>
gregwhitworth: That's over the 1.5 mil random URLs.
Chris: Thanks.
gregwhitworth: To Rossen's point we haven't seen interop issues.
Chris: Okay. I'm happy with this.
Serialization of font properties when system font is specified
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1586
Chris: myles points out on iOS and macOS the system font is a
cascade of fonts. What do you serialize out.
Rossen: I would love if serialization for this is a new proposed
constant/static variable proposed by dino so people can take
it and use it and not worry about the actual font.
Rossen: Coming back and saying here's your variable would be
awesome. I don't know what that means for compat, but it's
awesome.
Chris: mmm.
astearns: Since we don't have compat on this and the prop on the
table is to depend on something still being spec perhaps
this goes to fonts 4?
Chris: Fonts 4 is reasonable, but what text changes in fonts 3 if we
do that. Where is the text that says do a thing. Oh, in
setting font shorthand section.
Rossen: If we have an agreement to move to L4 you can work out
editorial details later.
Chris: Indeed.
Chris: Also effects CSSOM.
dbaron: One problem here is there's a bunch of behavior with no spec
result in CSS and impl have to make it up.
Chris: Yes.
astearns: I'm interested in getting this spec, but I'm also
interested in getting fonts 3 forward. Since we don't have
interop and it may take a while to settle on this I think
I'm happier doing it in fonts 4.
astearns: So dbaron we do need it spec, but maybe not this level.
dbaron: Fine.
astearns: Obj to moving serialization to font properties to L4 of
Fonts?
dbaron: Serialization of them when system fonts are used.
astearns: Yes.
Chris: Fonts 3 can say it's unspec?
astearns: I think it should say we intend to spec in next level.
RESOLVED: Serialization when system fonts are used to font
properties to L4 of Fonts
Default feature list should not require a list of features to turn on
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1267
Chris: There's a set of features that should be turned on. A should
not a must. dbaron commented saying he's fine with additional
enabled by default but didn't want to relax. I made tests and
sub tests for that section. FF and Chrome pass all. Safari
passes most sub tests. Edge doesn't impl this at all.
Chris: My feeling here is if we water this down we're forcing
content authors to stick a block of stuff to turn it back on
if they care about doing what open type spec says you should.
dbaron: I'd like to know what myles wanted.
astearns: One of the bits in the comment is a claim things can be
different for different platforms. Did you test that Chris?
Chris: I did. I did mostly Win 10 and then Safari on Mac OS. I think
it would be good to test on Android and IOS.
astearns: And FF and Chrome on Windows and MacOS
Chris: Right. I'm happy to test more.
dbaron: I'd still like to hear myles' answer for what he prop the
spec change to do
Chris: I do, but I think astearns is saying I need more data too.
astearns: dbaron can you tag myles and ask that question in GH?
dbaron: Yes.
Clarify what value is invalid for font-language-override and why it
shouldn't generate parse error
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1104
Chris: It is odd to have a parsing error based on string contents.
Chris: Because font language override is at risk anyway we should
move this to L4. I'm fine with that.
astearns: I'm fine with moving to L4. myles is as well it looks.
astearns: Objections to moving this issue to Fonts L4?
RESOLVED: Move the issue in https://github.com/w3c/csswg-drafts/issues/1104
to Fonts L4
Grammar of <feature-value-name>
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1000
Chris: No one has commented since February.
Chris: Part of the issue is because this is pre-bikeshed spec we
don't have a good link into grammar part of CSS.
Chris: Is Simon on the call?
astearns: Is this strictly editorial or is there a problem with
grammar because link isn't set up correct.
Chris: Grammar problem. Is this a single identifier or is it not.
Chris: I would be okay getting back to Simon asking for more details
on what's the issue.
astearns: Okay. Anyone else have any...can anyone else bring clarity
to this?
astearns: Let's tag Simon and get more information.
Chris: Thanks very much. I yield the floor.
astearns: Thanks for going through this to make sure fonts has a
good DoC
CSS Overflow
============
add overflow-block and overflow-inline to support CSS Writing Modes
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2000
fantasai: I think adding these properties makes a lot of sense. Just
need WG approval. I believe they should go into CSS
Overflow L3.
Rossen: I'm also in favor of this.
Rossen: As to the draft...css logical is fine.
Rossen: We currently have attempted to spec a bunch of properties
with their logical behavior inside CSS Logical. That's kinda
where we attempted to put all logical directions.
fantasai: That spec is because for most properties...they were in
CSS 2.1 and there wasn't a css 3 draft with those
properties. For scroll snap, though we put logical
equivalents in an appendix in spec.
Rossen: Borders?
fantasai: Yeah, L3 was stabilized a long time ago so we couldn't
change. L4 is expected to include logical keywords.
fantasai: Grid and Flexbox don't have physical equivalents.
Rossen: So we can close I'm in favor of adding a spec of the
requested behavior. If this lives in overflow 3...yeah...css
overflow 3 seems the better place.
astearns: Are you okay with L3 dbaron?
dbaron: That makes overflow 3 depend on logical. As long as that's
not an obstacle I'm okay.
Rossen: How about we deal with it when we get to it. We see which
pulls ahead. My intuition is logical is a bit of work, but
not that much.
astearns: I'm in favor of putting it where it makes sense and if the
race makes it problematic then we can deal with it.
Predictions on spec progress are often wrong.
astearns: Proposal: add the writing direction dependent overflow
values into CSS Overflow 3
astearns: Objections?
RESOLVED: Add the writing direction dependent overflow values into
CSS Overflow 3
CSS Box Model
=============
Allow the texts in input element to be painted into the top and
bottom padding area
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1941
dbaron: I can comment a bit. This is a long standing interop issue
that should be spec somewhere. Overflow behaves slightly
differently on input then everywhere else. Top and bottom
padding is different then left and right. Gecko had to
imitate the weird behavior of other impl because it was a
compat issue.
astearns: You're in favor of spec this and it looks like there's
rough consensus on putting it in overflow 3.
bradk: Isn't this more of a shadow dom thing where shadow dom
doesn't match between browsers?
dbaron: I don't think that's why the problem exists. It's that it
responds differently to top/bottom padding to left/right
padding. It doesn't have anything to do with the shadow dom.
bradk: Is it a bug or does it need to be spec?
dbaron: It needs spec because there's sites depending on it. We were
last to impl and got substantial number of bugs.
Rossen: We went through internal re-impl of the controls to make
them more driven my html/css and I think what this issue
suggests is for some controls there are missing box model
features that would allow one to create the compat input
type. We had to add a custom/private flexbox property value
that's not publicly exposed to handle that behavior.
Rossen: So what bradk is saying is partially true that we have a
different structure inside the shadow dom, but I also know
there are some missing layout primitives that would allow
one the flexibility of creating a compat control and I think
this is one.
bradk: I don't know enough about it to object. It just seems weird
we're spec special rules for inputs.
fantasai: I would put this into the UI spec because it seems more a
quirk about the control then about overflow impl. You
could have it so the input can be sized to take the
padding area so its content area expands into padding in
vertical axis. That would satisfy constraints without
overflow.
fantasai: We don't have to spec how it works, but if this is a
behavior of form controls we can put it in UI.
dbaron: I don't think it makes that much sense floating in UI spec.
<tantek> I tend to agree that it should go in box model
Rossen: What are the other use cases where we need this behavior so
it doesn't belong to UI. If we have those use cases this
should go to box model. If we only need it for input parking
it in UI for now is fine.
dbaron: I don't think it has use cases. It's that this is different.
If impl did it the normal way that would be fine, but this
isn't want impl do and people depend on it.
bradk: Is it related to how the ink for a descender can go into
padding?
dbaron: That's part of the overflow property. If you have overflow:
hidden that's cut off.
tantek: If this is for compat only another option is the compat spec.
Rossen: I like that.
dbaron: I think the goal of the compat spec is it wants to drive
itself out of existence as it moves things into other specs.
tantek: I thought it was a parking ground for things we wish didn't
exist.
dbaron: I think it's for things the spec authors wish didn't exist,
but it does in the real world so it needs to exist.
tantek: A compat section in box model?
Rossen: I don't think there's enough merit for this in box model.
Only use case is to allow overflowing text on top of padding
area for input type text controls. It's a very quirky
control specific behavior that we all emulate. Internally we
do use something similar to what's proposed here which is
allow the quirky bad behavior to exist so we have web compat.
Rossen: I don't believe it's requested for general box model. It's
too specific. If we put it in box model people will begin to
desire it and have quirky use cases.
astearns: If there's use cases then there's a reason for it to be
there.
<tantek> per Rossen reasoning I would prefer Compat spec
astearns: We're at time. It does seem like it should be CSS UI, but
it is overflow as well so perhaps a note in overflow about
this quirk.
dbaron: sgtm
astearns: Objections to spec this in CSS UI 4?
tantek: Everything Rossen said about box model is true to UI.
Rossen: Use case is input.
tantek: Use case is compat.
dbaron: UI is the placeholder for the to be written form control
spec. That's why it's suggested.
Rossen: Precisely.
tantek: I'm a -0 on it.
Rossen: As soon as we have a form control spec I'm in full support
of moving the quirk there.
RESOLVED: Spec this in CSS UI 4.
astearns: With that we're done. Thanks everybody for calling.
Received on Thursday, 11 January 2018 01:13:47 UTC