W3C home > Mailing lists > Public > www-style@w3.org > December 2018

[CSSWG] Minutes Lyon F2F 2018-10-23 Part III: CSS Fonts 4, Logical Properties, Environment Variables [css-fonts] [css-logical] [css-env]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 2 Dec 2018 06:25:01 -0500
Message-ID: <CADhPm3uh8UAEyBUHYycMaspERA2hFFtvFKQ3vwUus3R2Hn+Ypw@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 Fonts 4
-----------

  - The initial inclination was to solve issue #1744 (Adding lang as a
      font-face descriptor) using existing mechanisms like :lang() and
      not add a new descriptor. This will be noted in the issue in
      order to garner feedback from the proposers.

Logical Properties
------------------

  - The group discussed issue #1282 (Flow-relative syntax for
      `margin`-like shorthands) in hopes of reaching a conclusion
      while consulting with the i18n working group. Ideas floated
      include:
      - The new syntax should be in the regular value space.
      - No one was a fan of using a bang syntax.
      - There was discussion around prefixing or postfixing an 'l' to
          the existing properties (aka lmargin and marginl) but there
          was concern that it would break sort order and look like
          it's related to something it's not.
      - Another suggestion was to use separators such as 'margin: 1em
          / 2em / 3em / 4em',
      - Matching or aligning with Grid needs to be kept in mind as a
          part of this decision.
  - Ultimately the group couldn't reach a decision during this
      meeting. There was general consensus that the intended direction
      is property-name or value-level setting and discussion will
      continue on github.

Environment Variables
---------------------

  - There is a lot of interest in this spec and a desire to get it to
      FPWD soon
      - Need to solidify list of variables before FPWD
      - user-defined variables shouldn't block FPWD
  - Variables that are vendor specific was a point of contention
      - General consensus is that variables should be brought to the
          group to see if there is interest in exposing it across the
          web. If there is no interest then the variable can become a
          vendor prefixed variable.
      - This is supported by the resolution on issue #2820 which
          states “UA vendors MUST NOT expose built-in env() features
          to the web without going through that process”

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

Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: emilio

CSS Fonts 4
===========

Adding lang as a font-face descriptor
-------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1744

  myles: This issue is about the desire of making a font only used by
         elements that are on a particular language
  myles: So that each element with a particular language gets the
         right font attached to it
  myles: My particular feeling is that this is the latest step in a
         long sequence of changes to add more styling capabilities to
         @font-face
  myles: Selectors already do that, in font-face we already have a
         bunch of other descriptor, and this moves into the model of
         adding more styling to font-face
  myles: I don't want to implement all of CSS in @font-face, there are
         examples on the issue on how to do it using style rules
  <gregwhitworth> +1 to myles

  addison: If you were to put this in there's a bunch of interesting
           problems you need to specify, like how the lang tags match
           and stuff
  addison: ???
  addison: If you name a language for a font-face, you don't render it
           anywhere else? How do you enforce that?
  emilio: Isn't there a `:lang` selector you could use for that?
  drott: That's the example of the issue, yeah

  drott: I share myles' concerns and conflicting semantics between
         `:lang` an this
  drott: I think the intent is using the font in a more fine-grained
         way than unicode-range and such, and I think the example also
         covers this, you can use css variables to use it as the same
         font, but not sure if I missed any part of the use case
  addison: I think the idea is to affect how font-fallback works.
  addison: That's pretty common for CJK
  myles: We already have facilities to do this with CSS

  astearns: Looks like preference is to use existing mechanisms for
            that, and not use descriptors, we should put the minutes
            in the issue and let people comment

  florian: Does a note / suggestion in the spec about how to solve
           this problem seem useful?
  astearns: We should probably wait for more info from the proposers
            here
  r12a: While seeking further info, one thing to ask is how would you
        treat with multiple languages for a single font
  astearns: Can that be handled by selectors?

Logical Properties
==================

Flow-relative syntax for `margin`-like shorthands
-------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/1282

  fantasai: Currently css assigns values in shorthands to the physical
            longhands
  fantasai: It seems useful to make logical shorthands similarly
            convenient, which is useful for i18n
  fantasai: but we don't have a proposal for which kind of syntax we
            want to have for this
  fantasai: One's relative keyword, other is a bang keyword, others is
            a different property
  <dbaron> I would be pretty strongly against a ! syntax for something
           that's part of the property (i.e., not changing cascading).
  fantasai: One of the main restrictions is try to keep it
            sufficiently easy to type
  fantasai: Nothing on the thread seems to have stuck
  fantasai: Can we come up with some idea?
  fantasai: Other proposals were like global mode switches, etc
  fantasai: We could do some or multiple
  fantasai: [enumerates other solutions from the thread]

  addison: One of the challenges is when you go to make a rtl page
           layout you need to edit your stylesheet to flip your
           margins, ideally it'd be default
  TabAtkins: Something in the value space is maybe the best, like
             keywords
  TabAtksins: I'd be against punctuation, no precedent and hard to
              google, plus not compatible with CSSOM
  TabAtksins: Similarly for the bang
  TabAtksins: Nor mode switches, dbaron argued against it,
              serialization is also harder that way
  <dbaron> +1 to tab saying it should be in the regular value space
  <astearns> +1 to dbaron's +1 on regular value space
  fantasai: Typing "relative" is too long

  myles: Will the bang keyword be applicable on every property?
  fantasai: Only to some
  myles: So part of the grammar of the specific properties, right?
  fantasai: Yes
  myles: It'd be cool if it works with variables
  fantasai: That'd be terrifying
  TabAtkins: You should be able to drop a whole relative margin value
             in a variable
  TabAtkins: And you *cannot* put bang values into variables.

  scribe: myles

  emilio: Expanding shorthand into multiple longhands depending on
          syntax, like overflow, is not something that any other
          property has right now. So it's going to require specifying
          how you serialize when you have all of the 8 logical and
          physical margins. If you want the solution that people will
          implement fast, the best option is different properties.
          Then, all the machinery is there already.
  fantasai: How do we come up with a systematic way of coming up with
            a new property that is consistent, short, easy?
  emilio: Yes
  TabAtkins: We do "margin-se"
  emilio: Or "logical-margin"
  fantasai: It's way too long. Some people will write all of their
            stylesheets logically all of the time, and will stop
            using physical properties for the most part. The syntax
            needs to be ergonomic enough that it's practical for this.
  <jensimmons> It might be faster to implement, but if we hate the
               choice 10 years from now, it’s not a good idea

  florian: Will we push back against tab here about punctuation?
           ~padding ~margin?
  TabAtkins: If its property names, my objection is different. The
             only thing is that would not be an ident anymore.
  florian: Can we fix it?
  TabAtkins: Potentially but its a syntax change. It would be better
             for it to fit in the syntax.
  florian: If somebody is using a property that uses idents, this
           would break.
  TabAtkins: We try to not change syntax
  florian: This may warrant an exception
  TabAtkins: Yes. I think we can come up with a prefix in alphanumeric
             that's short

  scribe: emilio

  astearns: Do we have anything more on that?
  r12a: I agree with that fantasai and TabAtkins that it needs to be
        easy to type, I'd suggest `lmargin`
  r12a: I think `logical` is a much better word than `relative`
  <myles> +1 to not using "relative"
  <cbiesinger> +1 for not using relative
  <TabAtkins> I think `l` as a prefix works okay. I think we can
              reasonably prefix any word with that.
  <fantasai> I don't like prefixing with alphanumeric because it's
             less obvious what's going on and it won't sort correctly.
  <TabAtkins> *post*fixing with `l`?
  <fantasai> we use prefixes for the real name of the property, and
             prefix relationships are about shorthands
  <fantasai> postfixing makes it look like a different longhand of the
             physical shorthand

  iank_: Any of the bang syntax will probably have very funky
         interactions with CSSOM
  iank_: setProperty has a different argument for `!important` and such

  dbaron: So I think we all don't like the various bang things. I
          guess I'm not 100% convinced we want different property
          names, I think having it in the value would be slightly
          nicer even if we need to sort out a bunch of CSSOM issues,
          though it might depend on whether we find appropriate names
          for the properties
  dbaron: Different properties is probably faster
  <dbaron> I guess another option is using a delimiter within the
           'margin' value like 1em / 2em / 3em / 4em.

  jensimmons: Some of the things suggested where the good syntax is
              the old thing that nobody uses 10 years from now
  jensimmons: So even if might be more efficient or easier to
              implement we should pick a name that is a good name
  heycam: I feel like all of the syntax proposed so far is going to be
          a bit different and awkward, so I'm not sure the goal of
          finding a clean word is feasible
  jensimmons: I think lmargin is a bit more awkward than relative on
              the value
  jensimmons: Some of them feels smoother than others

  fantasai: Can you give us your opinion on the different proposals?
  jensimmons: I think -new is better than a new name, and keyword is
              better than a bang, but I can look at the list as we go
  jensimmons: how does it look in 10 years is something to look into
  jensimmons: Sticking a random letter in front of iframe hasn't
              seemed to hinder its adoption, it seems most people
              colloquially speak of iframes instead of frames
  Note: iframe stands for “inline frame”

  fantasai: Prefixing breaks the sort order, margin-something feels
            like a longhand analogous to margin-left or such
  fantasai: I'm a little skeptical about prefixing / suffixing. Has the
            issue of making it relate to properties it doesn't seem to
            relate
  cbiesinger: I think lmargin and such are a huge concern, we have
              some other messy margin

  majidvp: I think mode switch is the easiest. Is the concern about
           serialization really a problem? When do you have the
           problem?
  florian: We have some of that problem with box-sizing and such
  dbaron: I think we consider box-sizing a design mistake

  <jensimmons> imargin = international margin
  <cbiesinger> @mode "logical"; at the top?
  <fantasai> cbiesinger, yes that's one option
  <fantasai> cbiesinger, the other is a block like @media
  <cbiesinger> block seems worse to me
  <fantasai> cbiesinger, yeah I agree
  <fantasai> cbiesinger, even if we have a mode switch, we might
             want to have a way to put a specific declaration into the
             other mode, though
  <cbiesinger> fantasai, maybe but your escape hatch is margin-left

  <jensimmons> What Rachel just said makes me think that `margin: 10px
               5px 15px 25px relative;` is more of a “equal” to
               `margin` today… changing to a different property infers
               that it’s a different thing

  r12a: dbaron proposed separators instead, maybe we should consider
        that?
  rachelandrew: From the POV of teaching this a keyword means that you
                can look at your code and know what I'm using here,
                seems to infer the intent best
  dbaron: I suggested using separators, assuming we do want to move
          everyone to that, so that you can do something like `margin:
          1em / 2em / 3em / 4em`
  dbaron: It's somewhat obscure so it makes the distinction less
          obvious, but if it becomes the way to do it it may not be a
          problem
  fantasai: We use slashes on some places already, so not sure we
            could switch consistently everywhere
  dbaron: It doesn't need to be a slash, there are probably a number
          of symbols we haven't used yet
  <cbiesinger> +1 for dbaron's suggestion
  dbaron: The other reason it sort of makes sense to me is that the
          delimiter indicates a different relationship between the
          different values
  myles: Looks like if you don't use slashes code work and it'd look
         just wrong in RTL
  TabAtkins: Since the direction is different it at least sometimes
             will look wrong

  <jensimmons> also, should we go the other way — to match Grid — ….
               ???? Crazy. but also....
  <fantasai> yes, jensimmons, we will go the other way to match Grid
  <fantasai> Grid is using the direction we picked out for logical
             4-value syntaxes in general, we just never solved this
             particular syntax issue to have them :)
  <fantasai> It's interesting to note that the grid-area shorthand
             already uses slashes (and is logical)

  r12a: So you still have to deal with serialization and such
  dbaron: Yeah, that was emilio's concern, we need to solve that if we
          handle margins
  emilio: You also need to handle compressing and serializing when you
          specify all the 8 margins
  dbaron: You could condense those to two occurrences to the margin
          shorthand, but it's a bunch of CSSOM work
  dbaron: That's the 'this will take longer to get done'

  <rachelandrew> there is an example of individual properties here for
                 padding: https://codepen.io/rachelandrew/pen/OQrorW
  <rachelandrew> from
https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/

  emilio: Note that you also need to figure out how that interacts
          with the other sub-shorthands like margin-block /
          margin-inline
  TabAtkins: Yeah I think finding something using property names would
             be maybe the better idea
  fantasai: I think you still need a switch to change to physical in
            specific cases, and whatever solution we choose needs to
            be workable for that

  scribe: fantasai

  myles: Mode switch at the top of the file, many CSS authors don't
         know CSS that well and just copy-paste, so mode switches
         would end up being problematic for them
  myles: It's harder for authors to understand mode-switches, and
         they'll just get it wrong

  Bert: Said earlier that it might be a problem if margin expands to
        different properties based on whether there's a keyword or
        not. Is that true? Wouldn't it expand to all of them all the
        time.
  florian: Depending on the values, they are propagated to different
           values, but always expand out to the same set of longhands
           (all of them)
  dbaron: At the specified value it is, but at the computed value
          level, the two sets of properties compute the same values
  dbaron: The way we've added logical properties, they are distinct
          properties at the specified value level and they both exist
          in the object model
  Bert: If you set margin-start, it goes to margin-start
  Bert: If you set 'margin, does it also set margin-start or only go
        to margin-top
  dbaron: We're trying to find a syntax that sets the margin-start
          property
  Bert: Is it necessary?
  florian: ...
  florian: We don't have a logical shorthand. If we want logical to be
           the default way to write style sheets, we need that.
  astearns: Short answer is no the shorthand doesn't expand to all 8

  dbaron: Having the shorthand somehow set margin-top so that it sets
          the logical thing, could be doable, but would have some very
          confusing results
  florian: I didn't understand that
  Bert: Problem is that the 'margin' property doesn't reset the
        logical margins. Can that be changed?
  Bert: Like font resets font-size-adjust even though it's not
        mentioned
  fremy: I'm not sure why it doesn't set it
  fremy: These values would never be used
  fremy: It doesn't matter if margin resets them or doesn't
  fremy: If the order in which you reset them is such that you have
         the logical ones after the other ones its fine.
  dbaron: That would be one solution to part of the object model
          issues.
  dbaron: Others around serialization
  fremy: Somewhere we have to find principles of doing this, and need
         algorithm for this
  fremy: I didn't find it yet
  dbaron: Might be in a GH issue somewhere
  dbaron: Probably don't want to dig too far into CSSOM issues right
          now

  astearns: This was a good background on all solutions we could
            consider, but doesn't sound like we'll resolve today
  TabAtkins: Sounds like we're interested in a declaration-based syntax
  <TabAtkins> More specific than declaration-level. Property-name or
              value-level. (So not declaration glyphs, or ! values,
              etc.)
  fantasai: I think whether or not we use a mode switch, we will need
            per-declaration syntax. Style sheets written logically
            will sometimes need to use physical coordinates, e.g.
            positioning around images etc.

  fantasai: Whether the shorthand resets 4 or 8 of the longhands is
            actually still an open issue.
  <fantasai> fremy, were you thinking of
https://github.com/w3c/csswg-drafts/issues/3030?

  [break for lunch]


Environment Variables
=====================

  <astearns> https://drafts.csswg.org/css-env-1/
  <astearns> https://github.com/w3c/csswg-drafts/labels/css-env-1

  Rossen: This was mostly a status question
  Rossen: Where are we, why not FPWD?
  Rossen: We have ppl shipping some of it so what is happening

  TabAtkins: Quick bit of history, environment variables spec is
             something I put together after dino put together a PR on
             variables and then didn't respond to feedback
  TabAtkins: If Safari is shipping, need a spec asap
  TabAtkins: We've been thinking of shipping as well since then, so
             our implementers brought up more issues
  TabAtkins: We have a lot of issues here
  TabAtkins: I haven't been working on this lately, probably why not
             FPWD
  TabAtkins: If we want to fast track I can prioritize

  Rossen: Anything blocking FPWD?
  TabAtkins: There's one important issue to resolve on
  TabAtkins: List of variables must be vetted
  Rossen: It's a pretty short list
  TabAtkins: I think Safari is shipping additional variables beyond
             that set, is this true?
  smfr: probably?

  TabAtkins: Big feature to add is user-defined variables, but doesn't
             need to block FPWD
  Rossen: What is overall thinking about this?
  Rossen: Will enable variables supported by platform
  Rossen: How do we see such a spec getting to a stable version?
  Rossen: That list of variables will increase

  fantasai: We have an answer
  fantasai: We already decided that any variable that gets added needs
            to go through the standards process
  fantasai: It's not just a registry that lists things, we need
            to define behavior as well
  fantasai: so the regular standardization process is appropriate

  <myles_> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/ConstantPropertyMap.cpp#L53

  TabAtkins: On that note, issue 2820 is specifically about if you are
             producing additional variables
  TabAtkins: Need to put a MUST NOT ship non-standard variables into
             the spec

  smfr: We feel the need for an extension point where we can put
        things that we don't think should be standardized because
        they're only applicable to our platform
  smfr: Custom apple things that are exposed in CSS
  smfr: Like Apple system fonts
  smfr: webkit named image
  smfr: special appearance for apple pay buttons
  smfr: special color filter for doing inverted color messages
  smfr: system colors we expose
  smfr: These are all -apple-prefixed
  smfr: Then some that are fullscreen
  smfr: So I feel we need an extension point that we can add new stuff
        that's vendor-specific
  fantasai: If it is going to be exposed to the web, then it should
            not be specific to safari
  Rossen: It could be specific to that particular platform
  Rossen: So something available to Mac or Linux not available to
          Windows
  florian: Inverting screen colors is not apple-specific, not iOS
           specific, not Safari-specific
  florian: Having a pay button
  florian: Many things you listed in their current form are
           apple-specific, but
  florian: Many should be done in a vendor neutral way
  florian: e.g. should be able to have a pay button in Chrome as well
           as Safari
  fantasai: We want people to design for the web platform, not to a
            particular browser on a particular platform
  smfr: We have a fancy recipe for a backdrop filter that Apple
        designed for its content, and expose to people who want to use
        it to look like Apple
  florian: If something needs to works on all browsers, it should not
           be vendor-specific
  florian: If it should not work in all browsers, it should not be on
           the Web.

  astearns: Consider these sorts of things you're talking about as a
            type of user-defined variable?
  TabAtkins: They're still ua-defined, they won't be --
  TabAtkins: IIRC, when we were discussing how CSS doesn't want to use
             prefixes
  TabAtkins: If it's actually a platform-specific thing, not just
             experimental, then prefixes are appropriate to expose
  florian: Yes, but if something is only used for e.g. UI of iTunes,
           it should be prefixed *and* not exposed to the Web
  florian: If you expose to the Web, it's not vendor-specific
  TabAtkins: Anything exposed to iphone will be rendered by webkit
  TabAtkins: You write the web page to have special code when you're
             browsing with Safari
  florian: iTunes UI is an application, it's not like you're going to
           read its UI with Firefox
  florian: But if you have a website, then other browsers will read
           that page or try
  florian: Websites should be cross-platform
  TabAtkins: ...
  florian: iPhone has rounded corners, we should have iphone-specific
           thing for handling rounded corners ... but rounded corners
           are not iPhone specific
  florian: We shouldn't have an apple-specific feature for it
  florian: Having these things is not an Apple-specific thing, so it
           should be designed as a cross-platform standard feature
  florian: None of the examples given here are things that should only
           belong to one vendor

  [discussion of high contrast and microsoft-specific stuff]

  gregwhitworth: I feel like we're talking past each other
  gregwhitworth: Everyone likes standards, wants things to work great
  gregwhitworth: There's a bunch of stuff listed here
  gregwhitworth: e.g. high contrast, system colors, people want these
                 things
  gregwhitworth: These types of things, here's where interest, we
                 should start to standardize on these variables
  gregwhitworth: High contrast in variables, can present what we're
                 doing
  gregwhitworth: Can standardize them
  gregwhitworth: but have to ship at some point
  gregwhitworth: Where there's no alignment, then that's an avenue for
                 authors to access ios specific aspects
  florian: If I understand what you're proposing agree,
  florian: Bring things to the WG, if others might want to implement,
           then we work on standardize
  florian: but if it's clear that it's not of general interest, then
           ship as vendor-specific
  florian: That's fine
  florian: But don't agree with "just ship whatever you want", may or
           may not be candidate for standardization, get stuck with
           web compat
  hober: We've got product schedules and secrecy requirements
  florian: Sometimes you're constrained by business constraints,
           that's one thing. But we are discussing best practices here.

  dbaron: Have to think about what happens when web pages start using
          these things
  dbaron: Have trouble finding cases where if one of these
          browser-specific features becomes widely used, other
          browsers aren't going to have to implement it.
  dbaron: use example of inset-radius, let's suppose
          hypothetically, that we knew for sure that Apple was the
          only vendor that was going to ship a phone that wasn't
          rectangular
  dbaron: Even in that case, we need to know that this feature exist
          and that other browsers need to return zero
  dbaron: Or maybe sites depend on it being 10px, and we have to
          report 10px
  <heycam> dbaron++ ; authors aren't always going to provide fallback
           values in env()
  dbaron: But either way we need a spec about them, so we know what to
          do about them.
  <fantasai> dbaron++
  <florian> +1 to dbaron
  TabAtkins: That's compelling, I agree.

  Rossen: So let me try to close the discussion.
  Rossen: Clearly I believe there is interest in this spec, by more
          than a few of us
  Rossen: I want to see this spec get to FPWD
  Rossen: Sooner
  Rossen: We will work on details, but getting to FPWD should happen
  Rossen: Let's move on.

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0025.html
  <fantasai> RESOLVED: Accept proposal in the issue. “UA vendors MUST
             NOT expose built-in env() features to the web without
             going through that process” (Issue #2820)
  fantasai: We resolved on this in Sydney very explicitly. That goes
            in the spec.
Received on Sunday, 2 December 2018 11:26:05 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 December 2018 11:26:06 UTC