- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Jun 2017 21:44:56 -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.
=========================================
How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------
- The proposed spec text from the issue is: "Inheriting properties
of inline fragments that are contained in a ::first-line only
inherit from the ::first-line if those properties (1) do apply
to ::first-line, (2) do inherit by default, and (3) are not
custom properties."
- Point 1 of the proposal caused some concern as it may not be
necessary, but during the call some examples were provided
showing that it was important.
- RESOLVED: Take the behavior described in the issue and work with
it to make sure it works for compat.
typed-om editor
---------------
- Naina will be added as an editor.
"Serializing <an+b>" doesn't match what Firefox or Safari do
------------------------------------------------------------
- RESOLVED: Drop the 1 or -1 on an+b serialization
<percentage> shouldn't be able to resolve to <number> in calc()
---------------------------------------------------------------
- RESOLVED: Accept proposal (don't allow <percentage> to resolve
to <number> in calc())
FPWD as a dependency for [css-contain]
--------------------------------------
- RESOLVED: Move the text for integration between contain and
overflow to level 4 of overflow
Non-positive value should be invalid for 'resolution' feature
-------------------------------------------------------------
- RESOLVED: Spec should say resolution used to disallow negative
numbers. It makes sense to allow negative with the
boolean logic with some examples and that's for all MQ
with a numeric value.
Propagation of the :focus pseudo
--------------------------------
- This topic will be added to the F2F agenda to get further
discussion. Any testing before that should be added to both
the CSSWG & WHATWG issues.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0008.html
Present:
Tab Atkins
David Baron
Amelia Bellamy-Royds
Brian Birtles
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Dael Jackson
Dean Jackson
Peter Linss
Myles Maxfield
Liam Quin
Naina Raisinghani
François Remy
Melanie Richards
Florian Rivoal
Alan Stearns
Shane Stevens
Greg Whitworth
Regrets:
Rachel Andrew
Rossen Atanassov
Bert Bos
Angelo Cano
Benjamin De Cock
Simon Fraser
Daniel Glazman
Tony Graham
Vlad Levantovsky
Chris Lilley
Anton Prowse
Scribe: dael
astearns: Thanks everyone for calling at the different time.
astearns: As always, first thing is are there extra items? I got
the one from TabAtkins about percentage and calc.
astearns: Next topic is usually spec rec, but I've had no time to
summarize. Thanks to everyone that updated on group
list. I'll get something more up to date next week.
How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1097
fremy: I had been presenting that. We were waiting 2 weeks ago on
dbaron's reply.
fremy: dbaron basically agreed with the proposal and I think we
should probably just resolve on the behavior from the issue.
fremy: We were debating on best way to enter this into the spec,
it's editorial so it's up to the editor.
fremy: We were trying to describe how inherit works when child of
first pseudo element.
<dbaron> Proposed resolution was: "Inheriting properties of inline
fragments that are contained in a ::first-line only
inherit from the ::first-line if those properties (1) do
apply to ::first-line, (2) do inherit by default, and (3)
are not custom properties."
fremy: To recap: The element is a child of the ::first-line pseudo
and will generate the property and it will inherit by
default.
fremy: dbaron felt the approach was right if not the best wording.
fremy: We can work through the right wording, I guess.
astearns: Anyone with more comments or wants more explanation?
<tantek> this sounds reasonable, I'm wondering what the interop
situ is on this?
fantasai: I'm a little confused why we need to check if they apply
to ::first-line.
dbaron: That's what my comment was about. It wasn't about wording
but if that should be more general. Normally in CSS
applies to don't effect computed values. But applies to
pseudo elements does effect computed has been my
understanding. But we don't say that anywhere.
dbaron: My comment was that if that is the case we should a) say
it and b) remove condition 1 since it becomes redundant.
* fantasai thanks dbaron for the clear summary
fantasai: It could effect computed value on pseudo element. But
having properties inherit differently is really hairy.
There are a lot of properties where applies to is more
general
dbaron: It's possible that we need to separate applies to and if
properties apply to pseudo elements. That's more clear cut.
TabAtkins: I agree. The rest of applies to are editorial pointers,
but that's reasonably mechanically relevant
fantasai: There's a lot of properties where we say it applies to
everything, but that's because it inherits. We could
tighten that, but the majority of applies to aren't
tight.
Florian: And sometimes it's the opposite case where we state the
things it doesn't apply to. It's a fuzzy mess.
fantasai: It's not precise enough. If it's going to determine how
things inherit we need to be rigorous. I don't think we
should make the spec depend on if a properties applies
to. It should be if it's inherit or not.
dbaron: I think we need it for if it applies to pseudo elements,
but the specs aren't great on specifying. In Gecko we list
every property that applies to a pseudo in the code. If
it's doesn't apply the declarations aren't applied. That's
::first-letter and ::first-line.
fantasai: What's that case where we need the distinction?
dbaron: display
fantasai: It's not inheritable.
dbaron: I need to look at examples then.
fremy: I don't have a list of, but user-select would be one.
Florian: That's not inherited.
dbaron: I think the main reason inheritance needed restriction was
variables.
fremy: Yes, yes.
fremy: Variables, in that case, they could apply to any property.
But that's condition #3 where we say we don't generate
custom properties for ::first-line. There may be others.
fantasai: If we're going to have this condition I want an example
that is inheritable, not a custom prop, and doesn't
apply to ::first-line. If there's no such property we
don't need this conditional
fremy: Is there a list of properties that inherit?
fantasai: Indexes.
TabAtkins: That's not tracked across specs. It's on the to do list.
astearns: Sounds like we're converging on resolving to take the
proposal except possible condition 1 which needs a real
world example of why it's needed.
fantasai: Yes. I'm happy to resolve on the rest but I don't want
this conditional if it's not needed.
dbaron: Writing mode and direction are the two properties I've
found so far that are problematic.
Florian: If you try and change the writing mode on the
::first-line...yeah. Don't do that.
astearns: The treatment that is currently in the issue, whither or
not we have that first conditional, are writing mode
still problematic?
dbaron: They're inherited, not custom, but no one interprets them
as applying to ::first-line
fantasai: That's a good/interesting one. ::first-letter could be
in a different writing mode.
<dbaron> 'white-space' may also be a problem (with ::first-line
and 'pre')
astearns: To answer tantek from earlier, it sounds like we don't
have interop. Correct?
fremy: It's correct, I think. The issue was mostly Chrome allowed
a few more properties to inherit and the custom properties
weren't blacklisted in FF.
astearns: Can we resolve to accept the proposal, possibly
excluding condition 1 if there is no compelling example.
Florian: I think we found an example. Which leads to applies to
not being specific enough to rely.
fremy: We can agree on the behavior of this issue. I think we can
discuss the other issue separately. We can agree on the
behavior and discuss further what applies to means.
Florian: I think having or not having part 1 is a difference of
behavior.
Florian: I'm okay resolving this and filing issues against specs
to tighten applies to.
fantasai: That won't happen in any reasonable time frame. The
exclusion list should be explicit for now and then look
for a better way to distribute. Most don't take into
consideration ::first-line and ::first-letter and may
say "all applies"
fremy: Currently in pseudo spec there's a list of properties.
<fantasai> https://drafts.csswg.org/css-pseudo/#first-line-styling
dbaron: CSS 1 & 2 had a list of what properties apply to
::first-line and ::first-letter, but I think it was a
should.
dbaron: That may or may not be different to the applies to line.
We discussed about moving it, but we never did.
Florian: Should we point to pseudo 4?
<Florian> pseudo-4 isn't good enough for the list. It has the list
of "at least these must apply", it does not have "these
do not".
<liam> [css 2.1 lists for first-letter, font properties, color
property, background properties, 'word-spacing',
'letter-spacing', 'text-decoration', 'text-transform', and
'line-height', and then says, UAs may apply other
properties as well. ]
<liam> [ https://www.w3.org/TR/CSS2/selector.html#first-line-pseudo
just before 5.12.2 first-letter ]
<Florian> https://drafts.csswg.org/css-pseudo/#first-line-styling
<Florian> https://drafts.csswg.org/css-pseudo/#first-letter-styling
fantasai: What we need here is a list of properties that aren't
inherited from the pseudo elements and we can come up
with a more general approaches, but a good black list is
a starting point.
astearns: Sounds like we're resolving on the proposal with a
blacklist, but further define how to do it later. This
is the behavior we want.
<dbaron> It could have a list of "these apply", a list of "these
do not apply" and a note that if it's on neither list you
should contact the spec editor.
<fantasai> dbaron: That's a decent approach :)
tantek: I think I like the rough approach. I asked about interop
because every time we've tried to do this in the past
there has been compat issues. If someone wants to try this
with simple examples it could illuminate the likelihood of
this approach. I'd propose someone writes tests to test
their assumptions and show how bad the situation is.
tantek: It's a hard problem
astearns: Proposed resolution is try and specify this behavior and
see how that proposed behavior and interop goes.
RESOLVED: Take the behavior described in the issue and work with
it to make sure it works for compat.
typed-om editor
---------------
astearns: I'd like to add naina as an editor of typed OM
TabAtkins: I'm fine with that.
"Serializing <an+b>" doesn't match what Firefox or Safari do
------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1504
TabAtkins: If the a value is 1 or -1 you write the digit in
serialization. This violates general shortest form
rule. FF and Edge agree on not printing the 1 digit.
I'd like to change the spec to match that.
<fantasai> sgtm
astearns: Makes sense to me. Objections?
RESOLVED: Drop the 1 or -1 on an+b serialization
<percentage> shouldn't be able to resolve to <number> in calc()
---------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1463
TabAtkins: When you use percentage in calc it's allowed...you can
use it anywhere the usage would resolve a percentage
against another type.
TabAtkins: Applies equally, but per spec it applies to numbers.
This would apply in opacity, for example. Problem is in
typed OM when I'm trying to deal with types of
expression how we described in last F2F numbers have an
empty type map.
TabAtkins: If we don't allow percentage against numbers they're
easy to handle. It's always some type and I can later
fill in the type.
TabAtkins: If it could resolve against a number I lose that
ability. A percentage could be a type or none at all
and that makes the algorithm harder to describe.
Florian: Clarification: opacity you have percentage or number and
it's the same or you have line-height where percentage
and number aren't combinable. Are there cases where you
have percentage and number where they're combinable but
not same?
fantasai: They're combinable in the sense where number and
percentage in line-height ultimately resolve to length.
fantasai: We could, in theory, allow that.
TabAtkins: There's a reason not to. I'd like to never allow that.
There's a reason to disallow that.
TabAtkins: It makes the type of number incoherent. It's typeless
or has a type. It makes the algorithm to type check
math extremely more complicated.
<AmeliaBR> For line-height, percentage and number don't inherit
the same: percentage gets converted to length before
inheritance, number is converted at used-value time.
<fantasai> AmeliaBR: Yeah, and in width, <length> and <percentage>
have that same difference.
<AmeliaBR> PS, for length + number, there are all the SVG
properties to deal with, that treat number as
equivalent to px
<AmeliaBR> (e.g., stroke-width, stroke-dasharray)
TabAtkins: Big problem in when you multiply unitless. If a number
can represent a length if you multiple 1 x 2px is it a
length or a length squared?
TabAtkins: There's only two cases where this matters, line-height
and tab size. We could just add a unit. For now we're
okay. Calc doesn't allow you to treat a number as a
length.
dbaron: I'm not happy about treating number and percentage the
same. Number on line-height needs to be distinct from
percentage.
TabAtkins: They are. This is where percentage resolves to a
number. Opacity is the obvious example. I propose we
say a percentage never resolves to a number type.
fantasai: Does the percentage value of opacity compute to a number?
TabAtkins: I believe it computes to a number. That's what it has
to do. Opacity uses 0 to 1 as a percentage. The two are
equivalent.
<Florian> I'm with Tab here. The alternative seems to mean a lot
of complexity for no good reason.
fantasai: I think it would be surprising if someone tried to to
combine and it didn't work. If you're adding a variable
to an inlined you'd have to be very careful.
TabAtkins: I agree. That's why we originally wrote percentage can
resolve against number. But from a practical standpoint
dealing with types it doesn't work. You get an
incoherent thing where numbers can sometimes be used as
extra values. In the worst case you can never tell what
type an expression is if a number shows up.
TabAtkins: If I wasn't writing spec text I wouldn't have suggested
this.
fremy: Edge does not support percentage in opacity. This is the
first time I heard you can. I would be fine saying
percentage doesn't mix with numbers.
<AmeliaBR> percentage for opacity was a relatively recent addition
to the spec
TabAtkins: No one, even browsers that allow percentages, don't
allow them to mix in calc. Everyone is consistent in
not allowing this, I want to fix the spec.
astearns: By not allowing we're matching impl.
TabAtkins: Yeah.
dbaron: Some of that is because we don't have a spec for calc()
unit algebra.
TabAtkins: It's a lack of support not a positive we're doing this
on purpose thing. But removing it won't cause problems.
astearns: Objections to codifying this limitation?
RESOLVED: Accept proposal
FPWD as a dependency for [css-contain]
--------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1374
Florian: We resolved to take contain to CR, but overflow was not
fpwd so it was rejected. Most of the references from
contain to overflow go to 3 now that we cleaned it. 4
references are about fragmentation. Given that this is
least stable, should we change which spec has that text
so we don't depend on overflow 4?
fantasai: sgtm
astearns: It will get contain through the pipeline more quickly.
astearns: Objections to moving the text for integration between
contain and overflow to level 4?
RESOLVED: Move the text for integration between contain and
overflow to level 4
astearns: If there's a process issue we can re-resolve, but let's
use the old resolution
Non-positive value should be invalid for 'resolution' feature
-------------------------------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1454
Florian: We found this issue about resolution, but it's more than
that. There are a number of media features that take a
range and for which negative value makes no sense.
Resolution of -300 dpi makes no sense.
Florian: Old MQ it didn't really matter if we declared this as
invalid don't parse or value evaluates to false. The
difference it makes is in the OM. This has changed a bit
in MQ4 because we have unknown values.
Florian: If we say it parses and is false there width -300 is
false NOT width -300 is true.
Florian: I think it would be more useful to parse it and say it
evaluates to false. If it doesn't parse we don't know if
it is -300 or not.
Florian: We have, from the OM PoV we have interop on the opposite.
But the boolean logic isn't impl anywhere yet so it's not
observable.
Florian: I don't feel like breaking the interop is a major issue,
but maybe I'm wrong. What do you all think?
dino: I think we should do as you said and break the interop.
Florian: If they're relying on media resolution -300dpi this will
be fine. What this would break is very uncommon.
dbaron: Does the effect of the change...is it different on if the
browser impl the unknown thing?
Florian: Yes. It's part of impl the logic for nested and/or/not.
If you don't have that then it's undefined what this
does, I guess.
dbaron: Maybe the spec should have a note saying that the previous
version forbade negative values and that shouldn't be
removed until you impl this stuff.
Florian: That's fair.
astearns: Proposal: have the spec say you should parse negative
values if you implement this boolean stuff. Objections?
Florian: This is all media features with a range. width, height,
aspect ratio, color I suppose.
astearns: Spec should say resolution used to disallow negative
numbers. It makes sense to allow negative with the
boolean logic with some examples and that's for all MQ
with a numeric value.
dbaron: There should be a note that it's a change from the
previous version and we're looking for compat feedback.
Florian: Fair.
RESOLVED: Spec should say resolution used to disallow negative
numbers. It makes sense to allow negative with the
boolean logic with some examples and that's for all MQ
with a numeric value.
<AmeliaBR> [Tangent] A reminder that this and many aspects of CSS
parsing would have been easier define if there were CSS
Values data types specifically for non-negative or
strictly-positive values
(https://github.com/w3c/csswg-drafts/issues/355).
Propagation of the :focus pseudo
--------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1240
Florian: When we introduced :focus-within we tried to clarify
focus and active. What we attempted was to say active and
focus propagate to/from the same time. The spec prose for
that isn't very good. I think I authored that, sorry. It
also contradicts HTML.
Florian: I think we should clarify we do what HTML does.
Florian: Secondary, I think we resolved on a preferred behavior
which was also in disagreement with HTML. We should
either try and convince HTML to change their behavior if
we care about this. For now, we should point to their
propagation method.
astearns: Is their method well tested?
Florian: I think it is. I don't think it was fully interop before.
IE or Edge didn't used to have it, but there's more
interop now.
gregwhitworth: I haven't looked recently, but I thought most still
propagates in Edge.
Florian: I just tried recently and it didn't obviously propagate
in the general case. I still think it would be better if
it went both ways. There is an open issue on that in
WHATWG. I don't say we drop this, but having the
contradiction isn't useful.
astearns: So there's an open issue on WHATWG.
gregwhitworth: Could have sworn I tried to bring that back to
CSSWG. It seemed to most of the people in this
group felt this want the right behavior. I didn't
want people not in the room superseding that. I
didn't want to lose that. I can test more throughly.
Florian: In spirit I agree, but :focus is fairly complex. It's a
bit of a rabbit hole and I don't think we want to take
over all of that. If we want some part we need to figure
out where to split.
Florian: Looks like we won't resolve, but please look at github.
<fantasai> testcase:
data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4=
astearns: Can we resolve on removing the contradiction? Or is it
better to keep it open so the issue gets more :focus?
Florian: I thought it was better, but gregwhitworth argues that we
could lose all control.
gregwhitworth: I hadn't given it too much thought. Can we talk
about this in Paris? Or next WG call with everyone
on? Other impl were interested before.
<fantasai> +1 to f2f
astearns: Seems like bringing this to the F2F is a fair idea. It's
not that far. Let's do that. I'll put the F2F tag on it.
astearns: Please do add information to both WHATWG issue and ours
as you find it.
astearns: We're at the hour. I think that's it for the day. Thanks
for making it the different time. We'll try this time
again the first week in July.
Received on Thursday, 8 June 2017 01:46:02 UTC