- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Jan 2017 21:03: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.
=========================================
CSS Sizing Level 3 WD
---------------------
- RESOLVED: Publish WD of CSS Sizing L3
Avoiding accidental double spacing
----------------------------------
- Florian was concerned that the current spec for the
line-height-step property would lead to an author accidentally
getting the double height in a browser he/she didn't test
against due to a variation on the value of line-height:normal
caused by each browser calculating it slightly differently.
- There was broad agreement that the use case was valid and should
be solved, but no agreement on how to solve it.
- After some modifications, Florian's proposal was clarified
to specify that line-height:normal is a TBD fixed value
when the user sets line-height-step to anything other than
initial.
- The concerns with this proposal is that the authors may not
know why something that works with line-height:normal
suddenly stops working.
- If this proposal does go forward the initial value of
line-height-step should be none.
- Conversation will continue on the github issue to try and reach
consensus: https://github.com/w3c/csswg-drafts/issues/938
Add background-repeat-x/y
-------------------------
- Though at the most recent F2F there was a resolution to add
background-repeat-x/y due to web usage several browser
vendors didn't want to add the property because they didn't
feel there was such a strong need.
- RESOLVED Do not spec background-repeat-x/y for now
- It is Chrome's responsibility to gather more data to either
persuade other vendors to implement it or to decide that they
can remove it.
2017 Snapshot Issues
--------------------
- TabAtkins will look into the index problem so that the snapshot
can be published.
Revising CSS2 via NOTEs feedback
--------------------------------
- There were concerns about the decision from the F2F to use a
NOTE to maintain pending updates CSS2 not being the correct
process approach.
- This conversation will continue on the mailing list as that's a
better forum for this type of conversation, but people were
encouraged to actively reply on the list and to give specific
alternate proposals.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jan/0058.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Mike Miller
Rachel Nabors
Simon Pieters
Anton Prowse
Liam Quin
Melanie Richards
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Steve Zilles
Regrets:
Rossen Atanassov
Vladimir Levantovsky
Scribe: dael
CSS Sizing Level 3 WD
---------------------
astearns: Let's get going. Anything to add to the agenda?
astearns: Does anyone have an objection to publishing what we have
in the draft now?
RESOLVED: Publish WD of CSS Sizing L3
Avoiding accidental double spacing
----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/938
<tantek> for the record: https://drafts.csswg.org/css-sizing-3/
Florian: I raised this because the general mechanics are fine but
there's a case where we can improve.
Florian: You have your line-height that works normally and with
the line-height-step property you can round up. If you
provide a value that is some margin larger then the
line-height everything is fine. The problem is if your
line-height is unreliable.
<fantasai> [Florian is talking about the case of line-height:
normal]
<fantasai> [which varies between 1-1.2 depending on implementation
and available fonts]
Florian: If you don't set line-height and just set
line-height-step to a value somewhere within the usual
range of variations when you test on your machine it may
be fine but somewhere else it could be larger than your
step height and everything is double height.
Florian: I have a proposed solution. If you don't set line-height
but do line-height-step you compute line-height to 1
instead of normal.
Florian: If you're using line-height-step as intended this does
the right thing. koji isn't enthusiastic.
* fantasai thinks Florian's problem should be solved, and his
solution makes sense
koji: I think we already said in the notes that the author has to
set line-height for these properties. I'm not a big fan to
add more magical behavior. I understand the benefit but to
me looks like the down side wins.
Florian: Is there any downside beyond impl complexity? I don't see
a behavior downside.
koji: It looks like we rec not to set line-height if using step
sizing which makes it quite different.
astearns: I don't quite understand that objection.
astearns: We're just dealing with where line-height is normal. I
don't get how it follows that we're asking people not to
set line-height.
koji: I don't understand. Normal is initial value. So we ask
authors to set line-height and other things. This recommends
that the author not to set line-height.
astearns: I would expect us to say you should set line-height when
using step sizing. In the odd case where an author
chooses not to set line-height we fix a possible,
accidental double sizing.
Florian: If we make it more robust we encourage reliability. But
the breakage is subtle and only on some systems.
<fantasai> florian++
koji: Same for line font size too. I understand intent, but it's
clear that if things work they will not set the line-height.
Even if it's not our intention we're implicitly recommending
it.
<fantasai> koji, that's the problem: on the author's machine it
works, but on the viewer's it doesn't
<fantasai> florian, one issue with your proposal: currently the
initial value of line-height-step is zero, and this
creates discontinuous behavior.
<fantasai> florian, we'd need to introduce none as the initial
value
dauwhe: When I played with it it was quite common for me to
trigger this behavior. I also think of line-height as
fairly fundamental and most authors will use it and expect
it to work seamlessly.
<fantasai> dauwhe++
astearns: I take it dauwhe you're not in favor of changing the
unset line-height behavior?
dauwhe: I'm not sure on a solution, but I agree there's a problem
here and it's a general problem that it's too easy for the
property to create unexpected results.
Florian: fantasai made a point in irc too.
koji: The same happens to a font size too because initial for font
size varies by platform.
fremy: If you're doing it right you're using em to define the
line-heights based on font size. You should do the same for
step. You should never use px to define a line item. Using
em you should get right result.
<dbaron> you should really be using <number> values rather than
<length> values in em
koji: If you set correct values it works correctly. Florian wants
to solve when author forgets.
Florian: I'm not saying this is the only problem like this in css,
but either way we should have robust default. If we have
another way to solve I'm all ears, but I wouldn't be
happy about not solving it.
<fantasai> Agree with Florian, robust defaults are an important
CSS design principle
koji: I understand but it's as robust as without step sizing.
Florian: If you don't have step sizing it'll be somewhat okay in
all browsers.
koji: It's relative.
Florian: Double sizing is not okay when not intended.
koji: I'm not saying it's okay. I'm saying different line-height
is not okay.
TabAtkins: Florian proposed that line-height-step is non-initial
value we agree on a specific value for normal.
Florian: Correct.
TabAtkins: So what's wrong with that?
myles: Setting it to 1 it's very easy to get overlapping lines.
Florian: But you have line step height as well.
TabAtkins: That would ensure everything is 2em tall. The point is
does it seem reasonable to say the normal value should
be a known value to avoid cross browser difference in
rendering.
myles: Known value would be something derived from font.
TabAtkins: No. Right now normal is set to a specific value per UA
but it's allowed to vary. It's not based on font.
dbaron: It is.
Florian: It is to some degree.
Florian: If you set the line-height to a value wrong for your font
you'll get lines that overlap. If you set the step to
that same value you will get the overlap.
Florian: So that setting of line-height to a value when you set
line-height-step to a thing that makes sense creates no
new problem.
Florian: It's still terrible if you picked a terrible value, but
that's something else.
<dbaron> Another option here might be to define how 'normal'
depends on font metrics and try to become interoperable
on it!
<fantasai> dbaron, that helps but only somewhat: it doesn't handle
the case of using a font other than the one on the
author's computer!
<fantasai> dbaron, not that we shouldn't do it anyway, but it
won't solve this problem specifically
fremy: fantasai made my point on IRC. dbaron said we could
standardize for normal but it doesn't help if you choose a
font you don't have even if you say you use the font's
metrics.
TabAtkins: If you say use the font metrics for normal...but the
proposal was a specific value.
fremy: Yes. I think for the value we should investigate what
browsers are using. But I'm okay to fix a value...choose a
value in the case where you spec the step height.
fremy: We could even say line-height normal...it seems easier to
just choose a value.
<fantasai> https://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
<fantasai> "Tells user agents to set the used value to a
"reasonable" value based on the font of the element."
myles: What is step size it's a multiple of the line-height of the
primary font.
Florian: So you turn step size on and off?
astearns: Then the step size varies as line-height varies so you
don't get a vertical rhythm.
<fantasai> astearns, line-height-step inherits as an absolute
length
<fantasai> astearns, it won't vary by font throughout the document
Florian: It needs to stay constant as you go down the tree.
dbaron: It's also problematic if you mix fonts because you don't
know ratio of font line-heights.
astearns: I'm cautiously enthusiastic by saying line-height:normal
should be 1.2 instead of this weird inconstancy.
Florian: If 1.2 makes more people happy I'm okay with that.
TabAtkins: I think it's more common.
Florian: Sure.
dbaron: What we do now often is from font metrics. You're saying
not to use font metrics anymore?
Florian: Only if line-height-step is set.
TabAtkins: So astearns was saying let's set it at all times. If
that's problematic I say don't do it yet.
Florian: For line-height:normal in general it's probably useful
because some fonts are weird. But in this case the author
is setting a value.
koji: What about tall scripts that line-height:normal works great
today and an author turns on step sizing and all lines
overlap.
TabAtkins: They will overlap on every browser so the moment you
turn it on you'll see that they do and you'll change
line-height.
koji: If it's dynamically generated only some scripts overlap. So
author can't always predict.
astearns: The author won't necessarily see the connection is my
concern. They turn on line-height and we do magic, how
do they know to set the line-height
fantasai: You can use the line-height-step property and adjust
that. The numbers we're working with you set the
line-height-step to 1.2em and you're going to get the
behavior of 1.2 lines. If you set it to a value smaller
than 1em you'll get surprising behavior, but that seems
a rare case.
fremy: The rule is the step line should be at least as big as
line-height?
fantasai: I don't think so. You'll want that for headings.
fremy: Yes, yes.
fremy: Makes sense.
astearns: We've spent 20 minutes and I don't see an agreement. I
do hear consensus that this is an issue we should have a
solution for. Can we continue discussing in an issue?
TabAtkins: Can we see if there's objection to fixing
line-height:normal to a specific value when
line-height-step is not initial?
TabAtkins: We can set this down.
astearns: We can try, but I read that koji would object.
koji: I'm not sure I follow.
astearns: TabAtkins suggests we solve this problem by making
line-height:normal set to a particular value when step
size is set to something other than initial. Basically
Florian's proposal but without picking a number.
koji: I see. I'm not strong enough to object, but I'm not sure if
losing normal is good for authors.
koji: It's probably better for Latin, but international scripts
have higher heights.
fantasai: If you want to allow normal with line-height-step then
we need to add normal as a value to line-height-step
because anything you set line-height-step to it will
override.
fantasai: So if we want to allow the use of normal we have to add
it as a keyword.
<gsnedders> fantasai yes
koji: What I'm saying is to use a fixed value as a rhythm it never
wants to overlap lines.
TabAtkins: I'm not sure you understand fantasai's suggestion, koji.
astearns: I'm not sure adding normal to step sizing is that useful
because in a lot of cases you want something slightly
larger than line-height.
astearns: In any case, TabAtkins I don't think we have consensus
on the direction.
astearns: fantasai can you add your suggestion on the normal
keyword to the issue?
fantasai: Sure. If we make any behavior rely on the line-height
initial the initial value needs to be none.
TabAtkins: Yeah.
Florian: I would like to urge people to discuss this because I
think there is intent to ship from Blink so we need to
solve this soon.
fremy: It's fine to take time.
Florian: Yeah. But let's do it over a couple weeks not years.
astearns: There is consensus that this is a problem to solve.
Add background-repeat-x/y
-------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/116
astearns: We decided to spec these and mark as deprecated, but
gregwhitworth noted it means there's an expectation
everyone will implement. He'd rather mark as obsolete so
there's no requirement to impl.
gregwhitworth: I noted most of this in github. I'd really prefer
to have these marked as obsolete because they don't
even work as correct longhands to the short hand.
I'm looking for other opinions.
TabAtkins: Other browsers don't need to impl. I haven't heard
details on this not a long hand business.
gregwhitworth: It's in the issue. You can't do multiple
backgrounds in the long hand.
TabAtkins: Okay. That's fair.
gregwhitworth: I'd prefer...I don't want to impl these things.
That's where we're at. I'd like to hear other
opinions.
Florian: I don't think Google cares about spec compliant. Do we
need interop? If we do interop we need implementations.
gregwhitworth: There's only 1 browser with this. If it was a web
compat issue there would be other impl.
fremy: The problem is Chrome barely impl it. You can only set
repeat or no repeat. I checked on github and the majority
is just a test case file. That's prob why it's there is not
break the test case.
TabAtkins: Let's go back...you're looking on github for HTML
source code?
astearns: Let's not debate prevalence. There was data shown about
a significant number of pages using it.
<TabAtkins> (The number is .1% per our usage numbers, btw.)
fremy: We don't want to impl the property. What Chrome is impl is
something we don't want to impl. If they're willing to fix
maybe we can impl.
TabAtkins: We'll fix. Whatever.
Florian: I'm so confused about it being so prevalent Chrome needs
it but not prevalent.
smfr: I think it's because they inherited it from webkit and they
exposed it by mistake. We almost did it too. It's an easy
way to pass the background repeat.
Florian: That explains how it got there, but not the prevalence.
TabAtkins: Based on raw numbers it's above the level we're willing
to remove. If there's compat data that says a lot
aren't needed we can remove.
fremy: Is it more effort to remove than fix the impl. I think it's
easier to remove then fix.
Florian: I think the question is does it break the web. Easy
evidence suggests it might. Other browsers not seeing it
suggests otherwise. Deep data dive doesn't seem to have
volunteers.
astearns: The request to the group was to make
background-repeat-x/y as obsolete, not deprecated. This
is the least resistance path. I saw shans asking for
details from other browsers. TabAtkins are you okay with
obsolete?
TabAtkins: We'll just not put it in the spec in that case.
<fantasai> +1 to Tab
<fantasai> if we don't need to implement it, then we don't need to
invest time in speccing it
Florian: If it was spec in the past that makes sense for obsolete,
but if we've never had it and add it that makes no sense.
TabAtkins: It's a historical note at best, not obsolete. We're
proposing it because pages use them. We're trying to
make our custom stuff exist in a spec or remove. Based
on the least-effort-data-gather it looks like we won't
be able to remove. So it should probably be part of the
web platform and speced.
<tantek> whether or not it is "in the spec" historically is
irrelevant. it's whether or not it exists that's relevant
astearns: Given the resistance to the F2F resolution can I resolve
to wait on more data on background-repeat-x/y usage?
tantek: I think we need a straw poll on the record.
fremy: There's no need.
[everyone talks]
TabAtkins: I don't need a straw poll if I agree to what astearns
said.
tantek: I mean on the poll to obsolete it.
<gregwhitworth> My only desire for obsolete is for author knowledge
<gregwhitworth> I understand no one will implement it - and
understand you feel it's silly
TabAtkins: I'm not going to put an obsolete feature in a spec
tantek: I want people on the record saying they aren't going to
impl and want it in the spec as obsolete.
TabAtkins: It'll only come back if we say we won't kill it or
someone else says they will impl.
fremy: TabAtkins would you be fine marking as at risk?
astearns: It's not in a spec.
fremy: If we add it at risk.
TabAtkins: I'm not going to spec it. Let's leave as is until we
decide we don't need it or you'll deceit to impl it.
<liam> +1 to Tab
<zcorpan> TabAtkins++
<Florian> TabAtkins ++
<dbaron> Can we hear what Alan was going to propose before Tantek
interrupted?
astearns: Yes. That's what I was trying to get at.
astearns: I suggest to put it on browser compat data. We need to
find out if it should be spec, at the moment it
shouldn't go into a spec. We need to wait on data.
fremy: Who will provide data.
astearns: Chrome is the one that has to deal with it, so it's on
them to show if it's needed or not.
TabAtkins: Yeah.
<fantasai> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/background-repeat-x/
looks very wrong, btw
<tantek> so we're agreed on not specing it now?
astearns: Proposed is not to spec background-repeat-x/y for now
<tantek> +1
RESOLVED Do not spec background-repeat-x/y for now
gsnedders: do we need an action to look into it?
astearns: Because this is an internal Chrome thing it's on them
and at their priority. That's my take.
<gregwhitworth> agreed
<jensimmons> +1
<fantasai> well, the more we delay on this the more likely we are
to be backed into a corner
<fantasai> having one implementation in Chrome and none in other
browsers isn't a stable situation
<tantek> fantasai, hence I was trying to get at least a strawpoll
to capture current opinions
2017 Snapshot Issues
--------------------
<astearns> https://drafts.csswg.org/css-2017/#issues-index
<Florian> https://github.com/w3c/csswg-drafts/issues/935
ChrisL: Earlier we discussed what should go in there...
ChrisL: What modules. The only thing preventing it is the indexes.
They don't work because bikeshed needs an update or
Florian needs to be taught how to use it. That's why it's
not published.
Florian: I just posted the issue for how I tried to make it work.
TabAtkins needs to fix or document how to do it right.
TabAtkins: [catches up]
TabAtkins: Easy enough.
Florian: You need to tell me why my patch doesn't work.
TabAtkins: Will do.
ChrisL: Assuming that's done, we need a resolution to publish.
Florian: I think we have one.
ChrisL: Okay.
ACTION TabAtkins help Florian with index issue
<trackbot> Created ACTION-827
Revising CSS2 via NOTEs feedback
--------------------------------
ChrisL: Publishing as a note seems weird to me.
ChrisL: It's by definition non-rec track so something rec track as
a note is weird.
Florian: What we really have is an ED to track, but that leaves it
off the w3 domain. So we're suggesting a note mirror of
the things we're preparing to put in the stable draft.
It's not separate, it's a scratch pad.
Florian: That's why we went with that idea.
ChrisL: Is there anything there that requires patent disclosure?
If it's not CR or FPWD the review is not triggered.
Florian: We indeed only want fixes to 2.1. Also, these things will
get back to rec track. We put them on the real ED and do
CR/PR/REC every time there's something stable enough.
We're not jumping steps, we're cooking them on the side.
But if we had them on the real ED we'd have the immature
ones.
tantek: ChrisL your intuition is correct. It is weird. However,
the note itself is not rec track. The thing that is the
note will never be rec. This is a hack of the process to
achieve the goal we have of maintenance. Being aware of
this I took the task at the F2F to bring this to the AB
and say here's the group trying to do the maintenance
that's suggested and there's a hole in the process and it
needs a fix.
<fantasai> We're essentially publishing the "proposed errata" page
as a NOTE
tantek: In my opinion the use here of a note to get wider review
of errata makes sense. It's the only mechanism for us to
get a TR link for review. There could be better, but there
isn't one today.
ChrisL: Every rec is published with an errata link even if it's
empty. Is this because we want inline?
tantek: Yes.
ChrisL: AB is fine with this?
tantek: I didn't say that. I took an action to take this process
to the AB to point out this it is weird but this is the
best we can do following the spirit and letter of the
process to achieve the goal of maintenance.
ChrisL: Thanks.
Bert: We publish a WD and this note will be the same as the WD.
fantasai: We're not taking it to rec.
Florian: We're going to cherry pick things from it to send to rec,
but the draft itself isn't going.
astearns: The suggestion is publish a WD of css2 itself
Florian: It'll go to rec but over the next 15 years. We'll be
errata-ing for a very long time.
fantasai: I think we'll declare it's obsolete at that point.
fantasai: It'll be identical to REC-CSS2.
Bert: So this will be the last time we publish as a whole. Next
one we'll have holes in there. But why not do that as a WD?
The WD and the note are the same. The 30 errata are agreed
to.
<gsnedders> https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#rec-modify
seems relevant in the Process
liam: I think we have a process already. You publish the doc you
will cherry pick from as a requirements doc. It's on the rec
track and then becomes a note when satisfied. The process is
light weight and it doesn't sound weird.
Florian: But is it supposed to look like requirements?
fantasai: This is a copy of CSS 2 with some edits. It's not a
requirements document or a list of changes. It's an
exact copy with a few updates
Florian: To reply to Bert there are two ways for the WD. One is
keep it ongoing for however long it takes to stabilize
which will be long. We'll have 2.2 in many years.
Alternately we have a 2.2 every so often and then we do a
2.3 with some more things that have since stabilized. And
carry on. This is higher overhead and people that look at
2.1 won't auto-look at 2.4 even though it has been fixed.
Florian: We leave a trail of unfixed specs. It's higher overhead.
Bert: This new spec updates CSS2. It'll be a new 2. The latest
link will go to the latest.
Florian: The 2.1 link would be old.
Bert: Go to the dated one, yes.
gsnedders: I thought we had resolved.
Florian: Yes.
tantek: We did
Florian: Bert the 2.1 undated is the first link that shows if you
google css 2.1
Bert: We can fix that.
Bert: You said you doubt we'd get to rec quickly but the impl do
what the errata say.
tantek: That's a false assumption.
tantek: I don't think it's productive to brain storm this on the
call. Bert if you see a different cohesive process I'd
suggest you post that to the list or github so we can see
that.
<gsnedders> +1 to what tantek just said (not productive)
astearns: I think bert did post it to the list and I'm the only
one that responded.
astearns: I agree it's more productive on the list, but people
need to respond on the list.
tantek: I didn't see it and I didn't see a link to it.
astearns: Okay.
astearns: We're out of time for today.
Received on Thursday, 26 January 2017 02:04:57 UTC