- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Jan 2019 21:12:47 -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 Scroll Snap
---------------
- RESOLVED: Update the CR for scroll snap L1
CSS Values 3 & 4
----------------
- RESOLVED: Update CR of Values L3 and publish a new WD of L4
CSS Text 3
----------
- RESOLVED: Accept the edit to text L3 to normatively reference
unicode (Issue #3474)
- RESOLVED: Accept text for hyphenation in L3 (Issue #3434)
- In L4 of CSS Text the group wants to go deeper into addressing
open asks around hyphenation. fantasai will write spec text for:
- Have a more explicit rule on where to hyphenation when there
is an explicit hyphen
- Making don't hyphenate if there will be this many characters
before or after apply to hyphens as well (aka the e-mail/
T-shirt rule)
- Adding no-wrap to hyphens
- RESOLVED: Accept these changes [Clarification to prioritization:
https://github.com/w3c/csswg-drafts/issues/3463#issuecomment-450522790
]
for text L3
CSS Syntax
----------
- RESOLVED: Drop the 'drop the first @charset' rule (Issue #3464)
CSS Pseudo Elements
-------------------
- RESOLVED: Accept the edits here:
https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
(Issue #2474)
- The group ran out of time discussing Issue #2850 (color of text/
decorations), but it appears as though the solution will produce
the desired result. The original commenter will review the
proposed text in further detail to make sure it works.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0001.html
Present:
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Brian Birtles
Oriol Brufau
Dave Cramer
Elika Etemad
Dael Jackson
Peter Linss
Myles Maxfield
Florian Rivoal
Alan Stearns
Eric Willigers
Regrets:
Rachel Andrew
David Baron
Emil Eklund
Tony Graham
Chris Harrelson
Chris Lilley
Manuel Rego Casasnovas
Lea Verou
Scribe: dael
astearns: Let's get started. My apologies for not realizing I would
need extra webex considerations
astearns: Anything extra to add to the agenda?
CSS Scroll Snap
===============
Update css-scroll-snap-1 CR
---------------------------
DoC: https://drafts.csswg.org/css-scroll-snap-1/issues-cr-2018
Changes list: https://drafts.csswg.org/css-scroll-snap-1/#changes-20180814
astearns: Anything else on this fantasai?
fantasai: Not really. Minimal changes. It was obvious error fixes.
astearns: Remaining issues?
fantasai: Request to add events that we deferred originally. If
someone wants to draft that we can start a L2 draft
astearns: Assuming since some changes are from ericwilligers there
are tests?
fantasai: I did not investigate
astearns: ericwilligers? We're talking about republishing scroll
snap L1. 2 of the fixes in the DoC were raised by you so
wondering if there are test changes
ericwilligers: Yes, I've been writing tests
astearns: Objections to updating the CR for scroll snap L1?
RESOLVED: Update the CR for scroll snap L1
CSS Values 3 & 4
================
Republishing Values L3 and L4
-----------------------------
Changes list: https://drafts.csswg.org/css-values-3/#changes
astearns: Both WDs?
fantasai: 3 is CR.
fantasai: There were 2 changes so I didn't do DoC. Changes list is
all the comments.
fantasai: One is we did a resolution for pulling in value space
which drops top level hash multipliers. That shouldn't
effect implementations because it's a notation change.
fantasai: Clarified an interaction for numeric values outside the
range aren't always ignored so we said unless otherwise
spec.
fantasai: Very simple changes. Values 4 has no other changes then
those
astearns: Update to L4 is keeping them in sync
astearns: I think it's reasonable to not worry about DoC, but will
we have process problems?
florian: Technically DoC isn't required, we just have to show our
work. DoC is just a good way to do that
astearns: Ok
astearns: Objections to Update CR of Values L3 and Publish a new WD
of L4?
RESOLVED: Update CR of Values L3 and publish a new WD of L4
florian: There is work being done by Gérard Talbot on tests for CSS
3 Values
CSS Text 3
==========
Normatively reference Unicode
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3474#issuecomment-451288442
astearns: There was an edit
fantasai: Asking WG to review the edit. If everyone is happy we're
done
astearns: Looks good to me. Other comments?
<florian> +1
astearns: Want a resolution?
fantasai: Yes. We're in LC so I want to make sure it's clear
astearns: Objections to accepting the edit to text L3 to normatively
reference unicode?
florian: No objections and this helped with writing test cases
RESOLVED: Accept the edit to text L3 to normatively reference unicode
Prevent line breaking after explicit hyphens
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3434#issuecomment-450610535
fantasai: I committed a set of changes to clarify what hyphenation
is and when it's invoked.
fantasai: There were specific things we can do. Recommend if a word
contains a hyphen that breakpoint takes priority over auto
hyphen points. Could add no hyphens to L4. Also don't
hyphenate if there will be this many characters before or
after for L4. All this makes sense to me and wanted to ask
WG what makes sense to do
astearns: Argument to put first into L3 instead of 4?
fantasai: Just specifying a particular behavior. It wouldn't
increase scope of L3. We can also not specify it in L3
florian: Adding no-wrap to hyphen in L4 would be helpful. Since I've
done a talk on line breaking people have asked for this
feature.
florian: Priority on an actual hyphen over hyphenation I'm generally
in support. There was a nuance brought up where in things
like German you have [longword]-[longword] someone pointed
out in some cases you might want to break middle of other
words at high priority as well
fantasai: So you prefer to break at another word and not hyphen if
the break is close?
<florian> https://github.com/w3c/csswg-drafts/issues/618#issuecomment-255135593
florian: Here's the comment^
fantasai: I can imagine if you have 2 long words you would allow
hyphenation in them. but if auto hyphen point is 2 char
from explicit hyphen you would want explicit hyphen. I'm
not saying forbid the hyphen elsewhere, but encourage UA
to use that break
florian: Trying to find some way around this for UA to do something
smarter, either by keeping vague or we make it a must rule
but if a-b is in the dictionary it can override and do what
it wants
astearns: I think having a preference for the explicit hyphen but
allow at other points, for a UA to make a decision it has
to consider hyphenation points against something else like
a desired line break. A greedy linebreak algorithm will
just pick the highest priority we spec for the longest line
fantasai: Greedy means fill the line as much as possible. Doesn't
mean you can't say you prioritize breaks in that. Spaces
win but a hyphen in 2 char of break works
AmeliaBR: The desire is to keep some vagueness in rule for
prioritization because it does end up around how many
characters you will end up short. Spec has avoided strict
hyphen algorithm so far
myles: The smarter we get on hyphenation and line breaking the more
it seems to fit the text wrap multi-line type thing
<myles> what happened to text-wrap:multi-line? it isn't in the spec
any more, but there are references to it if you
search-in-page
<myles> https://github.com/w3c/csswg-drafts/commit/a0c27afa0a50c462584511e617a20b687eb892af#diff-94819ad75aa15ba8049b412f93d8cc04
astearns: Given that we are discussing pros and cons of specifying
if explicit hyphen is desired I'm inclined to push to L4
florian: Need to say something in L3.
fantasai: L3 spec if you break at punctuation it's required you
preform prioritization among your breaks. I don't think L3
needs to say anything more. It's not only allowed, but
encouraged
fantasai: Happy to push to L4. If we want something in the spec I'll
write it
florian: There's multiple ways. There's prioritization. There's also
if you have a hyphen and disallow the rest. Even looking at
German in the example this is allowed but not nice. Makes
me think it's akin to line break where there's strict and
loose.
fantasai: Okay
dauwhe: I'm fine with prioritization as fantasai wrote. I think that
expresses all other things being equal we prefer to break at
hyphen that's there, but there are other things algorithm
need to consider
astearns: I think we need a resolution to accept the current change.
fantasai did you want a feeling of the group if those 3
items should be worked on in L4?
fantasai: Yeah. If we want to add to L4 I can edit those in
astearns: First is accepting the changes in L3. Any objections to
the current hyphenation text in L3?
<florian> +1 for current change
RESOLVED: Accept text for hyphenation in L3
astearns: More explicit rule on where to hyphenation when there is
an explicit hyphen. Objections to adding that to L4?
<florian> +1
astearns: So work on that
fantasai: There's don't hyphenate if there will be this many
characters before or after and proposal is to apply that
to hyphens. You can't break if there's one character
before or after explicit hyphen
<AmeliaBR> aka the e-mail/T-shirt rule
<florian> +0 for hyphenate-limit-chars (no disagreement, just
haven't thought about it, but go explore)
<TabAtkins> e-
<TabAtkins> mail
astearns: Objections to add something in L4 around e-mail/t-shirt
rule?
astearns: Hearing none, let's work on that.
fantasai: Adding no-wrap to hyphens. None says don't do hyphenation
but you can break at explicit hyphens. No-wrap says don't
break at explicit hyphens either
<florian> +1 for nowrap in L4
astearns: Objections to dealing with not wrapping at explicit
hyphens in L4?
astearns: Let's work on that too.
astearns: One additional thing when talking about char limit. Does
it make sense to have char limit apply to each segment in
between explicit hyphens?
<fantasai> https://drafts.csswg.org/css-text-4/#hyphenate-char-limits
fantasai: Three values, required min for total characters to
hyphenate, minimum for characters before hyphen, minimum
for characters after
astearns: Minimum for 3 characters, you have 3 characters, explicit
hyphen, 2 characters, hyphenation break. Is that allowed?
fantasai: Need to check
astearns: Not sure if that should be a thing or not. There are more
then enough characters before hyphen
fantasai: Yes, but if there wasn't a hyphen seems weird to break
there
astearns: True. Maybe line length consideration needs the characters
fantasai: Then you would allow to break after 2 characters after a
space, too.
astearns: That's probably enough on this
Prevent line break after hyphen preceded by space
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3463#issuecomment-450522790
fantasai: This is [space]-foo and don't break before hyphen
fantasai: I added clarifications because there were points missing.
Prioritization should apply to all word separators. Second
was clarify prioritization isn't expected for
word-break:break-all
fantasai: Added you're allowed to consider a bunch of factors,
there's no limit but have a list of things you should
consider. Added a note that says prioritization forbidden
when there's line-break:anywhere. That's already stated in
line-break:anywhere
fantasai: Wanted to check WG is okay with changes
florian: Okay with changes, not sure they solve the issue. I suppose
hyphen is punctuation but it seems worth mentioning
explicitly. Even if you don't break around a / we do at
hyphen
fantasai: Have same problem with /. Have same with ".
florian: Do people allow break around / and "?
fantasai: Some allow break after a /. This is why it says SHOULD
fantasai: I don't think we can define all exceptions we want people
to follow. There's a lot of information in different
sources. We can't dictate everything
astearns: Given issue was opened on hyphen it would be nice to have
an example of a break to avoid with a hyphen to go along
with break to avoid after a /
fantasai: Can add an example
myles: These subjective choices should be made in a language and
local specific way
fantasai: Right
astearns: True and section does mention writing systems
florian: You said people break around /. FF doesn't. I think that's
what makes hyphen different. People do wrap after hyphen
fantasai: Sometimes it's appropriate
florian: Is when hyphen starts word
fantasai: space hyphen Chinese character, do we forbid that? I can't
define every rule for every system
dauwhe: My company has people who spend their day worrying about
these things and it's highly contextual
myles: I'm happy with should
astearns: I'm falling against additional examples because we can't
go through all bits of context to consider
astearns: Other comments on these changes?
astearns: Objections to accept these changes for text L3?
RESOLVED: Accept these changes for text L3
CSS Syntax
==========
"Drop first @charset rule" seems unneeded
-----------------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/3464
TabAtkins: This is in CR so need resolution. Way back in the day
when I wrote syntax I specified blink's behavior of
dropping the first. I later changed things so @charset
rules were not rules. None of the @charset things show in
cssom. Everyone adapted to that, at least blink and FF.
There is no @charset so we can drop the requirement to
drop the first
TabAtkins: Looking for objections and, if not, I'll fix the spec and
then put together the stuff for publishing
AmeliaBR: @charset is now an unrecognized rule or is it recognized
as a parsing instruction and then removed from CSSOM?
TabAtkins: Unrecognized rule. It's dropped like an @foo rule
fantasai: Proposal is drop all instead of drop first?
TabAtkins: There's already rules to drop all. But there's also a
rule to say drop first. This is nonsensical so I want to
fix.
fantasai: So spec says in one place it's drop first and in another
place drop all
TabAtkins: Yeah
astearns: I'm in favor of fixing things Boris finds confusing
fantasai: If Mozilla signs off I'm fine
TabAtkins: I think Boris effectively did
astearns: What about webkit?
astearns: Proposal: Drop the drop the first @charset rule
RESOLVED: Drop the 'drop the first @charset' rule
TabAtkins: This is the only unresolved thing. It's due for a
publication so I'll put together DoC. But if no one
objects I'd like a resolution to publish
astearns: I'd like to see the DoC since it's been a long time.
TabAtkins: No problem. There's been a couple changes
astearns: I don't expect many, but knowing which will be useful
TabAtkins: Last publish was in 2014
CSS Pseudo Elements
===================
Switching ::selection to use inheritance rather than cascade for
parent-child value propagation
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2474#issuecomment-380369965
fantasai: I made the edits we resolved on. Wanted to request review
because it's a significant re-write.
<florian> I did review, and I like it.
fantasai: If anyone needs time that's fine. But it would be good to
do an update WD at some point
<florian> would like to hear from would be implementors
astearns: Is this informative to have people come back? Or are you
okay with Florian's review?
fantasai: Either is fine
astearns: Does anyone want more time to read the changes?
florian: I want implementors to read because what's spec is
different then what's implemented. But what's implemented
isn't useful so we want them to switch. Based on a previous
read of the previous text that was objected to. But not
reading it and assuming it's fine wouldn't be good
astearns: Writing tests is easiest way to get implementors to pay
attention
florian: That's somewhere on my to do list
astearns: Let's get a resolution to accept these changes. Follow up
issues should be separately filed issue
astearns: Objections to accepting the edits here:
https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
fantasai: Unless emilio comes back and objects
astearns: Is he tagged in issue?
fantasai: I did not
florian: He opened it
astearns: Okay
RESOLVED: Accept the edits here:
https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
Color of text / decorations
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/2850
fantasai: As I was working on the model for this I figured it would
be useful to have this defined
fantasai: I wanted to double check that the WG thinks it's fine
AmeliaBR: A little concerned from agenda summary, but issue seems
that it's coming out of cascade where ::selection pseudo
element gets broken to separate pieces for selection
inside each element so selection inside an element with
different color will have different currentColor. Is that
correct?
fantasai: It would resolve to a single color, but just be a keyword.
If your value is currentColor you don't paint over text
decorations with another color.
AmeliaBR: Makes sense. Works if you think of it as many pseudo
elements in sequence. Wording in agenda makes it sound
that you can't set currentColor in pseudo selection itself.
fantasai: This is just for color property itself. currentColor
anywhere else behaves as expected
AmeliaBR: So it goes with this works by inheritence.
fantasai: I should double check spec, but that's what it should say
astearns: Other comments?
daniel: I came in mid-way, but this was my issue. What was that
about currentColor and inheritence?
fantasai: If you look at issue example there is text that's black
and underline black and there's a red word in there. What
I'm proposing is to clarify the behavior you expect that
the red will continue to be red if ::selection isn't given
a color.
<AmeliaBR> ::selection{ background: yellow} is treated as
::selection{background: yellow; color: currentColor}
fantasai: As I clarified it seemed it would be straightforward to
have a keyword to refer to this which is currentColor. So
I wanted to tie it explicitly rather then if you just
don't have a value. That way they can spec the behavior
daniel: If you leave out the value...in this example selection
leaves out color so it inherits from spelling error pseudo
element
fantasai: Way cascading is specified the ::selection inherits from
the parent ::selection not directly from the originating
element or another pseudo element
daniel: With you on that. If everyone agrees result should be bottom
example it seems like you have to inherit from pseudo
elements until you fall back to originating
fantasai: Could say inherits from pseudo element, but could be
confusing if you have overlapping pseudo elements that
don't form a tree
daniel: Do you have a solution that achieves expected result?
fantasai: If you read current ED...let me pull
<fantasai> https://drafts.csswg.org/css-pseudo-4/#highlight-painting
<fantasai> the topmost active highlight overlay redraws that text
(and its decorations) over the highlight overlay
backgrounds (and outlines, if any) using its own color,
with currentColor representing the color of the next
highlight pseudo-element layer below, falling back
finally to that of the originating element (the colors
that would otherwise be used)
fantasai: Second paragraph
florian: You're solving by having currentColor behave normally but
at used time fetch the correct color
daniel: As long as the resolution gets the expected result I'll be
happy
fantasai: That's the intention
daniel: I'm fine with that. If I have an issue with the wording I'll
file a separate issue.
fantasai: I would really like review on this section
daniel: I'm happy to do it offline. I'll send you an email and then
you can tell me if we need to have a follow-up
astearns: It would be good to have this conversation in the issue
daniel: I'll keep the issue updated
astearns: Thanks everyone. We'll be back at the normal time next week
Received on Thursday, 10 January 2019 02:13:49 UTC