- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Sep 2017 22:43:40 +0300
- 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.
=========================================
'border: 1px inset' is not interoperable
-----------------------------------------
- It was agreed that if more specificity is needed for inset that
work should occur in L4 of Backgrounds and Borders. However,
there is currently no use case for this level of specificity so
a use case is needed before this is revisited.
Define serialization for background shorthand
---------------------------------------------
- RESOLVED: Postpone this until there's further evidence of use
cases and move this to L4 if there is evidence.
Publication of Backgrounds L3
-----------------------------
- RESOLVED: Publish a new CR of backgrounds and borders.
Orthogonal Flow Constraint: viewport vs scroller
------------------------------------------------
- RESOLVED: Add max-height as well as height to the conditions that
define the height for resolution of orthogonal flow sizing.
- Florian will write tests for this resolution.
- It was suggested by Rossen to also add an informational note that
this does not guarantee the height will be correct.
<hash-token> seems to get type ID for sequence "#-\" followed by EOF
--------------------------------------------------------------------
- RESOLVED: Fix the check for a valid escape as described in #1821.
Meta bug for line height
------------------------
- The working group was reminded to review the tests (available
here: https://github.com/w3c/csswg-drafts/issues/1796) before
the F2F.
Publication for Multicol
------------------------
- RESOLVED: Publish a new WD of multicol
Avoiding accidental double spacing
----------------------------------
- Koji wrote some test cases
(https://github.com/w3c/csswg-drafts/issues/938#issuecomment-330561882
)
and wanted to understand if his test cases gave intentional or
accidental double spacing.
- In general, it was felt that the tests produced expected
behavior.
- Florian continues to be concerned that unintentional double
spacing can occur between browsers on the same code due to
differences in font calculations.
- Koji plans to write more tests to investigate these concerns
more.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Sep/0053.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Javier Fernandez
Robert Flack
Tony Graham
Dael Jackson
Brad Kemper
Myles Maxfield
Thierry Michel
Theresa O'Connor
Anton Prowse
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Alan Stearns
Regrets:
David Baron
Bert Bos
Emil Eklund
Daniel Glazman
Peter Linss
François Remy
Greg Whitworth
Scribe: dael
Agenda Setting
==============
Rossen: Let's get started.
Rossen: Good morning!
Rossen: As usual, first item is call for any additional items or
anything to change on the agenda.
rachelandrew: I posted to the list about putting multicol back to WD
if we could add that.
<fantasai> +1 to Rachel
rachelandrew: To republish as a WD since we've had so many changes.
I posted a run down of those changes.
astearns: We decided to take this back to WD because there were so
many changes. This is just a resolution to publish.
Rossen: I see and I see your email.
Rossen: Any other additional topics?
Spec Rec Next Steps
===================
Rossen: There was some good discussion on private list. I wanted to
draw attention to the first one.
Rossen: It's the topic of testability and that we want test cases to
support CR+ specs.
Rossen: astearns, are we closed on this topic? Is the final plan
what's in the private list thread? Or do we need discussion?
astearns: All I suggested was we keep issues open on CR specs until
we have test cases.
Rossen: And is there agreement on this?
astearns: fantasai and I talked last night and I think...I think
she's okay. Correct?
fantasai: Yep.
Rossen: Perfect. And thanks to everyone submitting test cases.
Rossen: We have a couple of topics on backgrounds & writing modes
which are tracked specs. I didn't see much about other specs.
Rossen: If there are issues you're facing with the tracked specs
please let us know.
Backgrounds & Borders
=====================
'border: 1px inset' is not interoperable
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1489
Rossen: Is zcorpan on?
[silence]
fantasai: I can probably take this.
fantasai: Basically the inset and outset borders we don't define
what color they should be. This is resulting in
non-interop, especially on 1px. Do we want to work on
aligning and, if yes, do we try and do this in L3 or L4?
<tantek> L4 please
fantasai: I don't think we can resolve on the result, but figuring
out where to put this work would help me agenda set.
Rossen: Fair.
<tantek> unless someone has citations of real world sites where
people are complaining
<tantek> and in which case, seriously, 1px inset/outside/ridge etc.
border?!? why?!?
Rossen: For the impl would this be something high on your list of
things to fix if we were to agree? Or will this be low
priority?
Rossen: I'm going to take silence as it being low priority.
Rossen: As an impl I would say this is low priority for us. We have
no had any reports of issues because of this. I don't see us
rushing this.
Rossen: One more call.
Rossen: If no one raises urgency I propose L4.
Rossen: So this is the call. If you're an impl and want to rush an
interop fix, now is the time.
<tantek> if Edge is still using the Trident border style rendering
code which was ported from Tasman, then I'd say that's a
good default if you want to specify something in L4 :)
<bradk> Wait for L4
Rossen: Okay, let's take this to L4.
Rossen: fantasai is this specific to 1px or inset in general?
fantasai: I'm not sure.
florian: From bug it looks like there's a general problem and it's
worse at 1px. We need to dig into details.
Rossen: Okay. Again, I don't think we can push inset to L4.
<tantek> I want to know what is the use-case for these odd 1px
border-styles
<tantek> seriously why are people doing them? what effect do they
expect?
fantasai: The spec has a not-specific statement as to what the color
should be, but no formula. All impl are spec complaint.
<tantek> yes that's deliberately vague to capture what
implementations did in the late 1990s / early 2000s
Rossen: Okay. Let's close saying if there are any more restrictive
spec changes that have to be made in terms of inset and
color computation, they would go in L4. Objections?
tantek: I'd want a use case. Why are you doing this? for what effect.
fantasai: The default rendering of hr to be consistent?
tantek: Why?
fantasai: Don't know.
<bradk> Inset borders are not in vogue anyway
tantek: That's why I want it documented. I'd prefer an explicit
statement saying we don't know why to do this. Most things
we do with a use case for what's trying to be achieved.
You're just making work without a use case.
<astearns> the effect we're looking to achieve is interoperability
in an existing feature
Rossen: Fair point.
Rossen: Your point will be in github. If we ever come back to this
we'll have to call for use cases and then revisit. Fair to
you?
tantek: Yeah.
Rossen: Anything else?
fantasai: That's it.
<tantek> suspects that anyone wanting border color precision like
that for 1px will explicitly compute and define each TRBL
side's color explicitly
<florian> tantek: I agree, and even more so once we add the multiple
borders we've resolved on, you even do explicit inset/
outset at subpixel level on retina screens.
<tantek> florian yes, retina-specific enhancements / experiments is
another good reason to leave those border-styles
underspecified.
Define serialization for background shorthand
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/418
fantasai: Defining serialization when splitting BG into multi long
hands. Question is do we tackle in L3 or is L4 okay?
fantasai: Is it really important to converge now or are people happy
to defer?
Rossen: I'll piggyback on tantek's point for use cases as well as
ask if there are any impl that are currently seeing interop
issues because of this and in any urgency to change their
serialization.
Rossen: I'm hearing silence which I am taking as no interest or use
cases.
Rossen: Obj to postponing this until there's further evidence of use
cases and move this to L4 if there is evidence?
<tantek> +1 to at least postpone to L4, and note explicitly no
use-cases
RESOLVED: Postpone this until there's further evidence of use cases
and move this to L4 if there is evidence.
Publication of Backgrounds L3
-----------------------------
<fantasai> https://drafts.csswg.org/css-backgrounds-3/issues-cr-2014
Rossen: Backgrounds and Borders was...that was bikeshedified last
week, correct?
fantasai: Yep. I updated DoC. We just closed issue 14. Issue 12 is
adding caniuse panels which we don't need to block on. All
other issues are clarifications or resolved.
<tantek> ship it!
Rossen: Awesome. Any objections to publishing new WD of backgrounds
and borders?
RESOLVED: Publish a new CR of backgrounds and borders.
<tantek> do we have a changes section?
<tantek> since prev CR?
<astearns> do we have tests for all of the backgrounds and borders
changes since the last publication?
<tantek> astearns also a good question - "tests for all ... changes"
- I was just looking for a "Changes from 2014 CR" section
myself to understand what those changes were. tests would
be great in addition!
<tantek> anyway I'm ok with resolving to publish an updated CR (
because that takes a while post-resolution) but I'd
strongly prefer if it the updated CR included a "Changes
from previous CR" informative section (e.g. in the/an
appendi x)
Orthogonal Flow Constraint: viewport vs scroller
================================================
github: https://github.com/w3c/csswg-drafts/issues/1391
florian: We resolved recently that if you had orthogonal flows with
indefinite size you would go with icb or closest scrollport
with fixed dimensions. We did not discuss, but I found out,
chrome & safari will also pick one up with auto height and
fixed max height and they'll pick up the max for the auto.
florian: Since we have almost two impl and that looks useful, I
suggest we add scrollport with fixed max height to what we
look through.
Rossen: The one thing I want to add is that when we talk about these
use cases and combinatorial nesting of scrollports the one
thing I don't see being addressed is with the addition of
flexbox and grid there are many different other cases which
will result in a scrollport having a defined width or height.
Rossen: And max height is not the only one. If your scrollport is a
grid item with height stretch that will also be defined.
Computing dimensions in which we resolve orthogonal flows
based on these two properties won't be enough in all cases.
Rossen: Having said this I also know there will be too many other
permutations we can come up with so I'm a little concerned
we will have something that kinda makes sense for blocks
only but when we come to more powerful layout features we'll
be back to having quite a bit of interop issues.
Rossen: My hopes is we either keep it more vague for now or we try
and nail down all the permutations.
florian: For other permutations don't you need to do some kind of
layout to figure them out?
Rossen: You have to.
florian: Max height you don't.
Rossen: You have to do the layout to figure out final size. If we
are striving for some height quality of guarantee which are
of the order if you have orthogonal flow we guarantee it
will always be visible. If we want that type of guarantee we
need to do a lot more work and take into account other
sizing and layout effects.
Rossen: If we don't want that guarantee I'd prefer less rigorous and
leave text as-is.
florian: I'm not sure question of level is right. Once one behavior
is established it is. I'd want to make it as convenient as
we can without depending on layout. Adding max-height seems
simple and useful. But if you don't want to I wouldn't
object, I just noticed this was the case in 2 browsers
already.
<fantasai> +1 to Florian
Rossen: Here you have 2 impl that have this behavior. And you said
they are not interop when border and padding is in play. I'm
a little wary of trying to define a little bit to nudge and
require others to follow if we're not going all way.
florian: Multiple browsers will have to change anyway because we're
not interop. But your argument of all or not at all...okay.
I felt it was easy fruit so I'd rather grab, but I don't
care strongly. I just felt it was new information.
fantasai: I agree with florian that including max height isn't any
harder then doing height. I don't see a reason not to.
Rossen: I've stated my reason.
fantasai: We're not suggesting look for the thing with max height
and use actual height. We're just saying use max height as
the limit. That's straight forward.
<fantasai> <div style="overflow: auto; height: 100px">
<fantasai> <div style="overflow: auto; max-height: 100px">
Rossen: florian I thought you said that would also work with height
auto.
florian: What I meant is what fantasai said. That height is auto we
can't use that height, but if max height is there we use
that. I meant what fantasai said.
Rossen: It's a pretty crude approximation. That you have max-height
doesn't mean you'll grow to that. You could have a fixed
height parent which drives overall height and you get
overflowing vertical text. I don't see how max height
guarantees.
florian: I don't think it guarantees, I think it's never worse and
sometimes better.
fantasai: You use smaller of closest scroller. If we look at closest
scroller and it has no height we'll use initial containing
block. Accounting for max height means we can limit. If we
don't consider max height we'll be bigger for sure.
florian: I think it's easy, sometimes useful, never worse.
Rossen: I would agree with that. It shouldn't make it worse.
Rossen: Are there other opinions on this topic?
Rossen: What is effect on the current tests for writing modes and
what would it do for progress?
fantasai: Simple edit to text. In terms of tests the impl have yet
to converge. I have an action item to write some tests for
this. Impl sometimes match speccing behavior sometimes
don't and that's because they're based on different logic.
This is prob simpler. Regardless of this change we'll need
specs to change.
florian: If we write extensive tests we won't get 2 impl any way. We
could write naive tests that pass.
Rossen: Current snapshot of the test suite was sometime last year,
correct?
florian: We resolved recently to change that so we need a new test
anyway. It's just what resolution do we write it to.
Rossen: I'm just trying to understand where we are.
koji: As I understand last thing had 2 impl. And you said safari is
slightly not interop.
florian: If you just test this thing you get impl. If you try and
interact to check for robust it breaks. If you just test
this it passes in chrome and safari.
Rossen: Other opinions?
Rossen: Obj to add max-height as well as height to the conditions
that define the height for resolution of orthogonal flow
sizing?
RESOLVED: Add max-height as well as height to the conditions that
define the height for resolution of orthogonal flow sizing.
Rossen: I also think adding a note that suggests there are many
cases that will break this...the current resolution is
brittle if we claim we guarantee the height.
florian: We don't offer that guarantee. If you want a note that this
helps but isn't enough, I'm fine with that.
Rossen: A note that it's not guarantee is good for authors.
ACTION florian to write tests for the resolution " add max-height as
well as height to the conditions that define the height for
resolution of orthogonal flow sizing"
<hash-token> seems to get type ID for sequence "#-\" followed by EOF
====================================================================
github: https://github.com/w3c/csswg-drafts/issues/1821
TabAtkins: Definitely a bug, needs change. I won't do details, but
if you have a malformed hash token at end of stylesheet
it can sometimes report it's valid even though it can try
and escape an EOF.
TabAtkins: If you have a hash token with like a # symbol [missed]
TabAtkins: hash -/end of stylesheet it's [missed] This is a small
bug to test if something is a valid escape. I don't check
to see if second character is EOF. If I add that it won't
have any additional consequences.
TabAtkins: All bugs were extremely minute. It's just that this is
not what was intended in the spec.
florian: Go for it.
Rossen: Any other opinions or concerns on this topic?
Rossen: If not we can resolve.
Rossen: Objections?
RESOLVED: Fix the check for a valid escape as described in #1821.
Meta bug for line height
========================
github: https://github.com/w3c/csswg-drafts/issues/1796
florian: As I've said before I made a bunch of tests and made
conclusions. Please review my tests so we can change the
spec. I think we're almost fully interop. Look into it.
Thank you.
florian: There will be TPAC drawings. But that will be more useful
if people read before.
Rossen: I see it's on the F2F agenda. This is a nudge to everyone to
look before the F2F.
Publication for Multicol
========================
<tantek> changes section?
<astearns> tantek - yes, many changes:
https://drafts.csswg.org/css-multicol/#changes
<tantek> thanks astearns, noting here FTR:
https://drafts.csswg.org/css-multicol/#changes
Rossen: Objections to publishing multicol WD?
RESOLVED: Publish a new WD of multicol
Avoiding accidental double spacing
==================================
github: https://github.com/w3c/csswg-drafts/issues/938
<koji> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-330561882
koji: The biggest problem for me is I'm failing to understand
definition. I made this example ^
koji: astearns gave me feedback that...the left most in the example
is normal. Second I applied line-grid. I applied line-box
contain to third.
koji: Second block has some double spacing but astearns says they're
all intentional. Is that common understanding within this
group?
myles: I think you're asking me?
florian: Everyone.
koji: Yeah. We need to distinguish intentional and accidental double
spacing and there isn't a clear definition.
koji: The second box is [missed] it happens accidental when font
metric is only slightly larger. Is that correct?
astearns: One thing I missed when I commented is that in your
example you are not changing line height. It's all the
same, but there are some fallback fonts making some lines
taller.
koji: Correct. It started with line-height:normal and it does double
step.
astearns: Right. With that new understanding I believe you are
correct that this is an example of the problem stated by
the issue. 2nd is accidental line spacing because the
author had line-height:normal and the grid set to
something without double spacing.
astearns: In my mind this is an intentional result of the feature.
You use rhythm to get consistent spacing, but the content
is such that you don't get it, so the spacing is forced by
the grid so the result is what authors should expect.
koji: Okay.
koji: Are you saying this is intentional or accidental?
astearns: Accidental in that if the author didn't know what content
would go into their grid, they didn't have control over
the fonts used, the person setting up line grid might not
have expected it. But they chose a rhythm, chose a grid,
so we're fitting author intent of using a grid.
astearns: I think this is an example of the issue as stated. I
personally don't think the issue is terrifically important
because author said they wanted to use a grid or rhythm.
koji: Thank you, that is exactly my understanding. florian do you
have different opinion?
florian: I'm struggling with how to say my opinion in 10 minutes
when in last F2F we tried to discuss and didn't conclude in
2 hours.
florian: I think when you have a case of line-height: normal and
then step to a value and large fallback the feature works
as intended. Similar case, technically, is line-height:
normal, line-height-step to a specific value, and the main
font on the engine happens to be a little too big and
everything is double spaced. That's not what authors want
and I don't know how to fix that.
florian: First problem happens with line-grid but the second one you
don't have the same problem because line-grid falls out of
main font size.
koji: But if you go to single grid in that case lines overlap. Grid
is fixed height, line-height is normal, and main font is lager.
florian: Line-grid you don't set it. That's the point.
koji: What you're saying is line unit is fixed size and line-height:
normal and the primary font is taller then specified unit. Is
that the case?
florian: I think yes, I didn't hear you clearly.
koji: If you compress the font to a single unit they overlap. You
said the font is taller then the unit, right?
florian: What unit?
<Rossen> how is this problem different than having display: grid
with fixed row repeats and auto placed grid items? ... some
will fit in one row others will cause two rows to be created
koji: Let me confirm. You said unit is fixed size.
florian: I said line-step-height is fixed, line-height is normal.
That font on that system gives a line-height taller then
step you set for primary font.
koji: If the font is taller and you try and fit in a single step you
overlap, right?
florian: Line-height is normal. They're larger then your step so you
double space everything.
koji: You said that's a problem?
florian: Yes.
florian: Double space everything is a problem if the rhythm works in
general and some fallback is taller that's working as
intended. If everything is double spaced that's not working
as intended.
florian: Primary font...I can't do this in 5 minutes.
florian: I tried for hours and failed.
koji: [missed] We mostly discussed which features people break and
that's not related.
Rossen: For the sake of furthering this, I think in summary I've
heard that florian's main objection is in case of fallback
font being slightly larger then primary you will have double
spacing when fallback font is used.
florian: That is how it works and in general not a problem.
Rossen: And because of this you expect everything will have double
spacing?
florian: No, what I'm saying is when the author sets a value for
line-step-height they don't know what the result of line
height calculation will be so they cannot set it in a
reliable way. So there is a possibility that things will
look right on one browser and not in the other because
different font metrics. That's not what the author wants
and a limitation. The double space everywhere on every
browser is what's wanted.
koji: I think I understand your point much better. I'll prepare
another test to see if my understanding is correct.
Rossen: Sounds great. How about we try and wrap here. Seems like
there's more clarity for koji in test cases you need to look
at. Why don't you create the test cases and bring them back?
Rossen: We'll take time during F2F on this, but if we can resolve
before even better.
Rossen: Okay for both of you?
koji: Okay for me.
florian: I have no objections to koji trying things out. I don't
think it'll change what I think of this feature.
Rossen: That's the top of the hour. Have a great day/night and we'll
talk next week.
Received on Wednesday, 27 September 2017 19:44:36 UTC