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:
              https://github.com/w3c/csswg-drafts/issues/666)

Hyphenation Priority
--------------------

  - RESOLVED: No change on this issue
              (https://github.com/w3c/csswg-drafts/issues/618).

Insufficient normative reference to UAX14 for the ID line breaking
    class
-------------------------------------------------------------------

  - 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

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

Regrets:
  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
            cases?
  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
           points.
  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
           dictionary,
  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
    class
------------------------------------------------------------------

  astearns: Let's go on to UAX14.
  Florian: There are no rules in CSS3 Text for ... line breaking ...
           rule.
  Florian: There are places that say such and such must behave as ID
           class
  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
            intentional
  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
           (break).
  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
           some.
  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
            subset?
  fantasai: Do we want to make the requirement only to punctuation,
            some subset, ... ? I don't see the point in calling this
            out.
  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
           well.
  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
             rules.
  <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
            rules?
  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
            background-position.
  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
             properties.
  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
            keywords.
  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
             load
  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
            slash.
  astearns: We could add a slash to background shorthand at some
            point.
  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
            shorthand?
  astearns: We are going to resolve where and which shorthands have
            slash
  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.3.1 : Thursday, 3 November 2016 09:39:58 UTC