W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Telecon 2016-11-02 [css-overflow] [css21] [css-text-3] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Nov 2016 05:38:53 -0400
Message-ID: <CADhPm3tYFzkjRfJ1A77jK_-Qj-Jq1k__2GgaV8=_KrWgJEdAFA@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.

overflow:hidden SHOULD or MUST not be scrollable

  - RESOLVED: Change this (overflow:hidden not scrolling) from
              SHOULD to MUST.
  - RESOLVED: For the quoted [Overflow spec] text we are changing
              SHOULD to MUST and MAY to MUST. (Text quoted here:

Hyphenation Priority

  - RESOLVED: No change on this issue

Insufficient normative reference to UAX14 for the ID line breaking

  - RESOLVED: No change to the spec because it already requires
              customary line breaking rules.

Add shorthands for alignment property

  - RESOLVED: Use place-items place-self place-content shorthands.
  - The group will revisit the use of slashes once people have had
      more time to review and think through the implications.

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Nov/0005.html

  Rachel Andrew (IRC Only)
  Tab Atkins
  Bert Bos
  Tantek Çelik
  Elika Etemad
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Myles Maxfield
  Anton Prowse
  Alan Stearns
  Greg Whtiworth
  Steve Zilles

  David Baron
  Dave Cramer
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Vlad Levantovsky
  Peter Linss
  Jen Simmons

Scribe: tantek

  astearns: We're postponing item 1 initial letter since Dave Cramer
            is not on the call.
  astearns: Any extra items for the agenda?
  astearns: Let's try #2
  Florian: I'd rather have fantasai for 2. [css-text-3] hyphenation
           priority https://github.com/w3c/csswg-drafts/issues/618
  Florian: can we do #4?

overflow:hidden SHOULD or MUST not be scrollable

  Florian: I was surprised to learn that overflow spec had
           overflow:hidden SHOULD
  Florian: I ran into it by reviewing a test depending on
           overflow:hidden not being scrollable to expose a bug on
           Safari on iOS.
  Florian: I believe everyone thought it should be a MUST.
  astearns: smfr replied saying that iOS behavior not intentional
            and he is ok making it a MUST.
  astearns: I'm grateful for that, and hope it gets added to the
            github issue.

  astearns: Anyone else have concern making it a MUST?
  bradk: I'm concerned that existing pages might be dependent on the
         scroll wheel scrolling it.
  Florian: I don't think the scrollwheel scrolls it.
  bradk: I'm not a 100% sure either but seems like there might be
         some browsers that might.

  <gregwhitworth> do we have a testcase for the scenario that iOS
                  works in?
  Florian: So yes we have a test case.
  Florian: It's linked from the github.

  myles: I agree with smfr that this is just a bug in webkit.
  iank: I think it makes sense to switch to MUST.

  Bert: I try to remember why we wrote it this way.
  Bert: I think it was just a case of writing English instead of
        spec text.
  Bert: I think we intended MUST
  astearns: PROPOSED change this (overflow:hidden not scrolling)
            from SHOULD to MUST
  astearns: anyone object?

  RESOLVED: change this (overflow:hidden not scrolling) from SHOULD
            to MUST

  myles: There are two spec places though
  myles: ... and ... - are those both going to get changed to MUST?
  Florian: I was talking about the first one.
  Florian: Maybe scrolling progammatically also sounds like
           attempting to write English not spec text.
  iank: When I was writing JS apps there's quite a few that depend
        on scrolling things programmatically.
  astearns: So we're changing MAY to MUST in both cases?
  Florian: I haven't considered that initially, but I agree with
           that as well. Same problem, English instead of spec text.
  <bradk> Must allow programmatic scrolling

  astearns: Backing up, is there any concern about changing both
  tantek: Looks like bradk is bringing up a distinction.

  Florian: I can phrase this as a non-awkward way.
  Florian: If I can avoid double negatives that would be good
  astearns: For the quoted [Overflow spec] text we are changing SHOULD
to MUST and MAY to MUST. Is that correct?
  Florian: mm-hmm
  astearns: Any objections?

  RESOLVED: For the quoted [Overflow spec] text we are changing SHOULD
to MUST and MAY to MUST. Everything gets changed to MUST.

Hyphenation Priority

  astearns: ok, hyphenation.
  <Florian> https://github.com/w3c/csswg-drafts/issues/618
  Florian: Hyphenation priority.
  Florian: For hyphenation there is a requirement that if there is
           an actual hyphen in the word, that hyphen should take
           priority over anything in the dictionary.
  Florian: I was looking on the spec for an opinion
  Florian: and the spec does have this for soft hyphens
  Florian: but not for "real" hyphens or hard hyphens.
  Florian: My initial call was extending the language that applies
           to soft hyphens to also apply to hard hyphens.
  Florian: It was pointed out that that language was very strict and
           completely disallows breaking at the dictionary break
  Florian: A smarter hyphenation engine may want to prioritize the
           hyphen over the dictionary break points, but still allow
           the other one.
  Florian: Should we say anything about this? and which way should
           we go?
  Florian: If we are in an engine that has a notion of prioritized
           hyphenation points then do explicit hyphens then
  Florian: but if we are not in such an engine, then we apply the
           same language about soft hyphen to hard hyphen.

  fantasai: I would prefer not to say anything about soft hyphens.
  fantasai: Especially ... there are cases where that is not the
            best place to break.
  fantasai: The reason a soft hyphen disables automatic hyphenation
            is because automatic hyphenation would do the wrong thing
  fantasai: and thus you want to suppress the automatic hyphenation.
  myles: Everything fantasai said is correct.
  Florian: Yes I agree as well.
  fantasai: I think prioritization of hyphenation is something we
            should not be getting into.
  Florian: Point taken. ok. we can close this.
  fantasai: Resolution no change.
  astearns: Any objection?

  RESOLVED: no change on this issue (618)

Insufficient normative reference to UAX14 for the ID line breaking

  astearns: Let's go on to UAX14.
  Florian: There are no rules in CSS3 Text for ... line breaking ...
  Florian: There are places that say such and such must behave as ID
  Florian: But it does not seem to be required.
  ChrisL: It sounds like ...
  fantasai: We normatively reference UAX14 that deal with line
            breaking chars.
  fantasai: The rest of UAX14 is informatively reference and that's
  fantasai: because UAX14 pairs table is not going to get you the
            best result.
  fantasai: We are saying here is some information about
            line-breaking, please incorporate
  fantasai: but here is some additional information to consider.
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Aug/0321.html

  ChrisL: Sounds like two separate things. UAX14 as a baseline, and
          not, do whatever you want.
  Florian: Pick a subset of what UAX14 says about the ID class
  Florian: because there is one part that is completely reasonable.
  Florian: Between chars of the ID class, and between chars of the
           ID class and regular stuff
  Florian: then there is a wrapping opportunity
  Florian: but if between ID class and a word joiner then don't
  Florian: What do you do around punctuation, small kana
  Florian: I don't think we should define that.
  Florian: but we can point to the line-break property which defines
  Florian: But between Kanji and a letter ...
  fantasai: ... do xyz width
  fantasai: We have wording that says do the appropriate thing, e.g.
            in the word-break property.
  fantasai: I don't want to prescribe any kind of algorithm beyond
            you must honor all the line-breaking control points
  fantasai: because then what about this set of characters vs these
            other characters.
  fantasai: Do we normatively require ... tailored ...? this is not
            our job.
  fantasai: Going through Unicode and determining all the line
            breaking chars is UAX14's job and it's not great.
  fantasai: it's not our job. bunch of ... and ... and ... ? why
  fantasai: Do we want to make the requirement only to punctuation,
            some subset, ... ? I don't see the point in calling this
  fantasai: It should be fairly obvious that if you are not putting
            breaks between two Kanji characters then you are doing
            something wrong.
  Florian: Can I depend on that for a test?
  fantasai: Yes.

  ChrisL: Is it a baseline or is it do whatever you want?
  Florian: I was trying to get a minimal sensible subset of UAX14
           that everyone can agree on, and I agree your concern that
           without any normative requirement it makes me nervous as
  fantasai: ... words break according to their customary rules as
            described above.
  fantasai: If you're doing something that is obviously not
            customary then it is obviously not customary and
            obviously wrong per spec
  fantasai: and that is the case for break in between two kanji.
  myles: Also expressing support for fantasai.
  Florian: If we agree the spec is sufficient for testing breaks
           between Kanji
  Florian: then I am ok.
  fantasai: The text I quoted is enough, the word customary is a
            normative requirement.
  <fantasai> https://drafts.csswg.org/css-text-3/#valdef-word-break-normal
  astearns: There are tests that rely on customary western line
            breaking as well.
  astearns: There are tests I've written that look at line breaks,
            and they try to make it the most obvious of what I think
            the line breaking should be, but I'm not sure I can find
            an assertion in the spec that proves it
  astearns: and I'm ok with that ambiguity in creating tests
  Florian: I'm ok with if we are ok with having this ambiguous but
           normative way of doing tests, then I am ok with it.
  Florian: I don't want this to be a reason to reject a test.
  fantasai: We also allow testing may.
  astearns: Maybe that is the threshold for putting explicit
            normative text in the spec.
  astearns: That if you have a test that is reasonable for your
            interpretation of customary, and someone disagrees, then
            we need to add text to the spec.

  astearns: So the resolution is ...
  Florian: I would prefer long worded resolution.
  <fantasai> RESOLVED: Spec already requires sane line-breaking
  <fantasai> (so no change)
  <fantasai> astearns: s/sane/customary/
  astearns: Any objection to resolution of no change to the spec
            because it already requires customary line breaking
  astearns: Alright that is resolved
  <Florian> proposed resolution: no change, the spec uses
            intentionally fuzzy wording but does have normative
            requirement about following customary line breaking rules

  RESOLVED: No change to the spec because it already requires
            customary line breaking rules.

Add shorthands for alignment properties

  astearns: Alignment shorthands
  astearns: ... and slash separator.
  fantasai: I don't know if [missed]
  fantasai: My main concern with the slash is that we don't have one
            ... now, so we end up with two that are almost the same
            but not.
  TabAtkins: The scroll snap align is very simple
  TabAtkins: this is not
  TabAtkins: so we cannot do it without a slash.
  TabAtkins: Without it would be largely worthless.
  TabAtkins: We could allow you to only specify one (and another
             with space), which is possible but also weird.

  fantasai: Do we want scroll snap to also allow slash?
  fantasai: What happens if we extend scroll snap?
  TabAtkins: Reasonable to me.
  fantasai: It's confusing that they're not consistent.
  fantasai: It would be nice if they were consistent.
  fantasai: Otherwise authors would have to remember ...
  fantasai: We also have background positioning without a slash.
  fantasai: I'm not really happy the fact that you can't just be
            like here is how you do centering.
  fantasai: We don't have any consistency here.
  TabAtkins: Sure, if you wanted to do it with a single value, you
             specify center and you're done.
  TabAtkins: I get your concern otherwise.
  TabAtkins: And it's not really you want to do start in one axis
             and center, for scroll snap you say start center, and
             for ... you say start / center.
  TabAtkins: I'm fine with adding slash to scroll snap.

  fantasai: We also have the consistency issue with
  fantasai: They all take the same subset of keywords.
  fantasai: Alignment keyword, followed by another
  fantasai: We can't do three of them because background-position
            does not take /
  TabAtkins: And we can't do zero of them because that restricts
             drastically what we can specify in the alignment
  fantasai: But in the alignment properties the only thing we not
            allow is a distribution value in addition to a fallback.
  fantasai: We could positionally restrict the safe and unsafe
  fantasai: The only problem is a distribution keyword followed by
            an alignment keyword.
  fantasai: Only problem is ... if you only have one item
  fantasai: you wouldn't be able to do that in a shorthand [missed].
  TabAtkins: ... restrictions on what value types are allowed are
             subtle and hard to remember
  TabAtkins: sometimes you can cleave it well
  TabAtkins: but this time it is grammatical.
  TabAtkins: Slash is annoying to remember, but at least it's just a
             quirk that you realize for a particular property
  TabAtkins: rather than a subset of syntax, much higher cognitive
  TabAtkins: because if you do try to write it and get confused.
  TabAtkins: The cognitive load of slash vs no slash is less bad
             than any syntax restrictions we could put in.

  fantasai: I think that point is correct but I'd like more feedback
            before we resolve.
  astearns: I think I'm fine, I prefer putting the slash in, so that
            we can express everything we want in the shorthand.
  astearns: I think we can have that as a general rule, if a
            shorthand could become ambiguous, then we could add a
  astearns: We could add a slash to background shorthand at some
  fantasai: That would make background shorthand problematic to
            distinguish ... from ...
  astearns: It sounds like we can resolve today to use place as the
            alignment shorthand.
  <gregwhitworth> we can bikeshed later once we see the spec

  astearns: Does anyone object to using place as the alignment
  astearns: We are going to resolve where and which shorthands have
  astearns: We are going to get back to this
  astearns: Resolution is that we are going to use place-* as ... or
            what is the actual?
  astearns: What is the actual shorthand?
  TabAtkins: place-items place-self place-content
  astearns: We resolve to use those three place-* shorthands
  astearns: and we will revisit where to use slashes in shorthands.

  RESOLVED: Use place-items place-self place-content shorthands.

  astearns: Anything else?
  fantasai: Hanging punctuation issue?
  Florian: I thought you were supposed to come with some detailed
           wording that we would look at?
  fantasai: So the wording in IRC was not sufficiently clear?
  astearns: I was waiting for wording in the issue itself.
  astearns: If that's it for today
  astearns: we can end a few minutes early.
  astearns: Thank you everyone for calling in and thank you tantek
            for minuting.
  <astearns> the initial letter topic was postponed to next week
             when we hope dauwhe can attend
Received on Thursday, 3 November 2016 09:39:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC