W3C home > Mailing lists > Public > www-style@w3.org > January 2019

[CSSWG] Minutes Telecon 2019-01-09 [css-scroll-snap] [css-values] [css-syntax] [css-text] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 9 Jan 2019 21:12:47 -0500
Message-ID: <CADhPm3sMAjV+imVkk1cG+P4hCSVomONqORsvmisckOGvn=comQ@mail.gmail.com>
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:
              for text L3

CSS Syntax

  - RESOLVED: Drop the 'drop the first @charset' rule (Issue #3464)

CSS Pseudo Elements

  - RESOLVED: Accept the edits here:
              (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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0001.html

  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

  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
  fantasai: Very simple changes. Values 4 has no other changes then
  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
  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
  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
  <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
  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
  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
  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
  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
  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
  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
  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
  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
  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:
  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:

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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:09 UTC