W3C home > Mailing lists > Public > www-style@w3.org > August 2017

[CSSWG] Minutes Paris F2F 2017-08-03 Part IV: CSS Display Level 3, CSS UI 4, CSS Fonts 4, CSS Counter Styles [css-display] [css-ui-4] [css-fonts] [css-counter-styles]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 29 Aug 2017 17:55:48 -0400
Message-ID: <CADhPm3s7gOv8bO5xM+5F_a_wNW++NkrR5wwu6+7EWPXZgusjkw@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 Display Level 3

  - RESOLVED: Leave 'display' syntax as-is for #1496
  - RESOLVED: For 1246, inlinification of 'block flow' goes to
              inline flow-root aka inline-block, blockfication of
              inline flow-root & inline-block go to 'block'
  - RESOLVED: For 1486, issue is moot because 1246 resolution was
              reverted (above)
  - RESOLVED: 'inline flow-root' serializes in getComputedStyle as
  - RESOLVED: Accept 1550 "flow never establishes a BFC. Instead,
              all cases which require a BFC are handled by switching
              the inner display type to flow-root at used value time
              via becoming a formatting context."
  - RESOLVED: Move "becoming a formatting context" section back to
              css-contain, mark ruby/inline as open issues to figure


  - RESOLVED: Put a note into "appearance" saying it's not ready to
              implement, list the possible solutions discussed here,
              ask impls which they want to do. (Issue #1250)

CSS Fonts 4

  - RESOLVED: All font-* properties are reset by the font shorthand,
              except font-presentation and font-synthesis.

CSS Counter Styles

  - RESOLVED: Same resolution as yesterday (The language of a
              counter is computed based on the language of the
              element that the counter applies to at the point of


Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Scribe: nainar

CSS Display Level 3

flow-root syntax
  github: https://github.com/w3c/csswg-drafts/issues/1496

  TabAtkins: First three issues are deeply inter-connected.
  TabAtkins: Second one is keystone issue here.
  <Florian> 1550 is not listed in the wiki, but also interconnected
  [whiteboarding again]
  [TabAtkins draws a table with columns flow/flow-root,
             rows block/inline, and values
             block / BFC / inline-block / inline (clockwise) ]

            | flow   |   flow-root  |
     block  | block  | BFC          |
     inline | inline | inline-block |

  TabAtkins: Block has to inlinify to inline-block, and inline-block
             has to blockify to block.
  TabAtkins: To make this happen properly - we check if the value is
             a special value.
  TabAtkins: We could break the congruence between legacy values and
             the two-keyword values so that we define that inline
             blockifies to block and inline.

  Scribe: fantasai (with nainar scribing fantasai speaking)

  TabAtkins: Which would mean that inline-block won't behave the
             same as inline flow-root
  TabAtkins: even though they're the same thing.

  TabAtkins: I have an alternate suggestion:
  TabAtkins: It's still a little confusing, but maybe better
  TabAtkins: That would avoid breaking existing implementations of
             flow-root, which have already shipped.
  TabAtkins: First suggestion is that we stick with block and inline
  TabAtkins: But rather than just two values of flow/flow-root, we
             have three, calling 1 2 and 3 atm
  TabAtkins: in increasing order of BFCness.
  TabAtkins: Legacy inline is inline+1
  TabAtkins: legacy block is block+2
  TabAtkins: inline-block is inline+2
  TabAtkins: 2 is the "keep my children together" value
  TabAtkins: 3 is the even stronger one, so flow-root is block+3
  TabAtkins: and inline+3 is inline-super-block.

  Florian: What is an inline-super-block?
  Florian: In which cases do they behave differently?
  TabAtkins: If it blockifies it blockifies to flow-root
  fantasai: When does that matter?
  TabAtkins: You contain floats and stuff
  TabAtkins: So if you have a plain inline block.
  Rossen: You have two inline blocks, and they are inside a flex.
          They both get blockified.
  Rossen: If those have floats inside, those floats don't affect
          each other.
  Florian, fantasai: Flex items are BFCs
  Florian, fantasai: When does CSS blockify something and not turn
           it into a BFC also?
  TabAtkins: I can't think of any case...

  Florian: What about the block+1 case?
  TabAtkins: tiny-block
  TabAtkins: tiny-block inlinifies to inline.
  Florian: Concrete example?
  TabAtkins: If you have a normal block inside of a ruby container.
             If you put a tiny-block into a ruby then it turns into
             a regular inline
  TabAtkins: falls out of the 2x3 array.
  TabAtkins: I guess then we have two values that fall out and
             aren't really useful.
  TabAtkins: So in that case, I think we should have a diamond.

  Florian: So how's that different from 2x2?
  TabAtkins: block and inline-block correspond.
  TabAtkins: I guess flow-root doesn't inlinify? Or maybe becomes
  [TabAtkins draws a bunch of arrows]
  Florian: I don't know if this is useful.....
  iank: Why can't we ?
  TabAtkins: Because block has to inlinify to inline-block, and
             inline-block blockify to block.
  fremy: getComputedStyle, right
  Florian: That and display: inherit, which nobody does.
  Florian: Could we say that everything that BFCizes makes you go
           from block to flow-root and independently from ...
  Florian: Maybe?

  TabAtkins: So given that block+1 doesn't have a use case, and
             neither does inline+3 ...
  fantasai: I think its silly to have a bunch of combinations that
            are not useful - can't see how this is a better system
  TabAtkins: I want inlinification and blockification to be simple
  TabAtkins: 2x2 grid doesn't work, have to special case things.
  fantasai: I think you're overemphasizing the importance of
            inlinification being defined as swapping a keyword
            in or out.
  fantasai: If we take arrows this set of 4 values correspond like
            that it will be better.
  fantasai: We either have to syntactically disallow or have them do
  TabAtkins: ....

  [TabAtkins redraws original 2x2 grid
      TabAtkins draws arrows representing inlinification and
  TabAtkins: You don't have pairs, a flow-root inlinifies to an
             inline-block which then blockifies to a block.
  TabAtkins: But that doesn't seem to be a practical concern.

  Florian: [Florian frantically pointing at the whiteboard yelling
  gregwhitworth: Can you please use words?
  Florian: If the only difference between block and flow-root is
           being a BFC
  Florian: becoming a block ...?
  TabAtkins: Inline block currently becomes a block when it
  TabAtkins: It just happens to be an BFC in all these cases, but
             its computed value is 'block'
  TabAtkins: e.g. for flex items, if you specify 'display:
             inline-block' and ask for its computed display you get
  TabAtkins: Generally the case, also for abspos etc.
  TabAtkins: Because 'flow-root' didn't exist 15 years ago,
  TabAtkins: I don't like it, but I'd be okay with just doing this
             (points at 2x2).
  TabAtkins: So it's fine.

  TabAtkins: OK, so we can analyze the other things.
  TabAtkins: So if we have blockification /inlinification algos just
             explicitly map these values in the 2x2 grid.
  TabAtkins: Then the next issue is ...
  TabAtkins: This solves 1246
  TabAtkins: where bz points out we get the wrong computed style
             (get flow-root where breaks legacy).
  Florian: I believe the board is a re-resolution of 1246.
  TabAtkins: Also resolves 1496.
  TabAtkins: Suggested resolution is that blockification of an
             inline flow-root aka inline-block is defined to go to
  TabAtkins: And inlinification of block flow special cases to
             inline flow-root aka inline-block
  fantasai: 1486 is still open?
  astearns: So sticking with 1496

  RESOLVED: Leave 'display' syntax as-is for #1496
  RESOLVED: For 1246, inlinification of 'block flow' goes to inline
            flow-root aka inline-block, blockfication of inline
            flow-root & inline-block go to 'block'
  RESOLVED: For 1486, issue is moot because 1246 resolution was
            reverted (above)

  fantasai: Inline flow-root what is the computed value if we aren't
  fantasai: The serialization?

  RESOLVED: 'inline flow-root' serializes in getComputedStyle as

'flow' inner display type should never establish a BFC
  GitHub: https://github.com/w3c/csswg-drafts/issues/1550

  TabAtkins: This is oriol asking, mechanisms that turn BFCs, why
             not make them all resolve to display: flow-root
             instead. And we can't due to web-compat.
  Florian: It's not that there are 2 behavior for flow, there are 4,
           and flow is way overloaded.
  TabAtkins: 2nd and 3rd are the same thing [missed some of list]
  TabAtkins: Flow creates regular blocks and sometimes BFC
  TabAtkins: That's just the way it is.

  TabAtkins: oh, I see.
  TabAtkins: Actual suggestion is to change the value at used value
  TabAtkins: That doesn't mean anything, because it's post box tree
  TabAtkins: Used values are for turning box tree into fragment tree.
  dbaron: No, used values are just how we describe transformations
          that happen after inheritance
  dbaron: i.e. anything that's post-computation.

  fantasai: Isn't this editorial? He is saying that instead of
            describing things as we have it - we should vocab and
            change flow to flow-root for used value.
            "This change should have no effect in practice."
  TabAtkins: ...
  TabAtkins: Computed value is everything before you inherit, and
             used value is everything after inheritance.
  Florian: No way to distinguish, but you could say that box tree is
           computed off of used value of 'display'
  Florian: introducing this concept as a way of explaining what
  fremy: All the old specs we already have will be even more
  TabAtkins: We already have had to edit every spec
  TabAtkins: e.g. "height behaves as auto" thing.
  TabAtkins: Not actually every spec anyway.
  TabAtkins: Seems okay.
  TabAtkins: dbaron?

  astearns: Given item wasn't on agenda, and this is first time
            apparently anyone understood it...
  TabAtkins: OK, can discuss later.
  Florian: It was sort of on the agenda, next issue links to this
  astearns: OK, let's switch the topic and get minutes posted to the
            correct issues.

Becoming a formatting context
  github: https://github.com/w3c/csswg-drafts/issues/1457

  TabAtkins: Big issue is 'contain' property
  TabAtkins: which requires element to establish a formatting
  TabAtkins: But it's not meaningful, can't just say it establishes
             a formatting context out of the blue, e.g. an 'inline'
  TabAtkins: Could say that it turns into an inline-block, though.
  TabAtkins: But can't do that to Ruby.

  TabAtkins: So what should we do here?
  TabAtkins: Most cases it's a no-op, grid/table/etc is a no-op
  TabAtkins: Block has an easy answer: switch to flow-root.
  TabAtkins: Inline has an easy answer: switch to inline-block.
  TabAtkins: Ruby is the only one that has a difficult issue.
  Florian: In other cases, we haven't had a problem with this
  Florian: e.g. 'overflow' doesn't apply to inline/ruby, so don't
           have to worry about these cases.
  Florian: Similarly column-span only applies to block-level
           elements, so no problem there.
  Florian: The only case where we have a problem is 'contain'
  Florian: which needed to apply to 'inline' and 'ruby'.
  Florian: So we need to establish terminology, and oriol's
           suggestion works for this.

  Florian: The alternative is to not add terminology for this, and
           just say that these things blockify and [missed]
  fantasai: Ruby can be block-level.
  fantasai: Ruby spec defines block Ruby. You can't turn into a
            inline block Ruby which is what you were trying to say.
  Florian: Might be worth leaving existing places the way they are
  Florian: and have 'contain' blockify, and the rest is obvious.
  Florian: If there's an easy way to define this, then we should,
           and then call into it from all these places.
  Florian: Oriol's suggestion solves this case.

  TabAtkins: So what should we do for ruby?
  fantasai: Two solutions here. Third one is what you were trying to
            do - ruby makes an inline block ruby thing. No use
            case, so not a good idea.
  fantasai: Second thing we could do - florian mentioned to blockify
            ruby and the inline. That is inconsistent with inline
            block. They get to stay as inline-blocks.
  fantasai: Weird to have ruby turn into a block element.
  fantasai: You could turn all inline level things into block level
  fantasai: Last thing, this aspect of contain doesn't apply to
            inline/ruby - the author should change it into a block
            first. Author then chooses to make the display
  TabAtkins: No reason not to apply contain to inline-block.
  TabAtkins: You mentioned block ruby.
  fantasai: Confirms that if you specify display block ruby you get
            a block with ruby inside it.
  fremy: Ruby does special alignment things.
  Florian, fantasai: it's not different from inline

  TabAtkins: Can we make block ruby a BFC?
  TabAtkins: Only thing is that if you have a float, it won't
             intrude the way it does for regular blocks.
  Rossen: No reason to have inline layout of ruby be different from
          regular inline layout.

  fantasai: Why not go with the last option?
  TabAtkins: ...
  fantasai: To apply to neither inline/ruby - you the author must
            turn it into an inline-block or block (depending on the
            author's preference)
  TabAtkins: Ok, I'm down with that.
  dbaron: Issue is that contain is that authors won't know what
          effects to get.
  TabAtkins: Then it's a no-op, they're putting it there for trash
  fremy: They're not getting worse performance.
  dbaron: Elements nested inside each other, and accidentally stuck
          property on inline instead of the inline-block.
  fremy: dom inspector can show that it doesn't apply.
  astearns: What if they applied it to a box that was block, and
            then changed it to an inline and now they lose the
            performance benefits.
  fantasai: Keep in mind that if you had a contain on there - when
            you turned it into an inline you would not get the
            layout you expected.
  fantasai: If we didn't ignore it we would be forcing it into an
            inline then.
  fremy: Your question is like someone getting performance benefit
         from ? and then turning it off and wondering why benefit is
  astearns: I like the fact that 'contain' doesn't have the
            blockification transformation with this.
  TabAtkins: That would be a significant layout change, whereas for
             other things its relatively minor.

  Florian: After understanding it, you used oriol's terminology, so
           regardless of whether we become an FC, I would support
           adopting oriol's terminology,
  Florian: It seems to me that we are getting closer to fantasai's
           position, which is to not define the idea of becoming an
           FC, and for all the situations except contain that may
           have been ambiguous it was good enough
  Florian: and for contain we will eliminate the problematic
           situations so that it is also good enough.

  TabAtkins: First resolution is for 1457, which is "what does it
             mean to become a formatting context"
  TabAtkins: resolution is that blocks become flow roots, inlines
             and rubies can't establish a formatting context, and so
             any property that tries to invoke this must exclude
             them somehow.
  TabAtkins: So we will change 'contain' accordingly.
  astearns: dbaron?
  dbaron: I think ppl often have a bunch of nested elements and the
          display types are pretty random, and that usually just
  TabAtkins: Kinda, until people are like "why is there a 2px gap
             below this thing?" and it's because they have an
             inline-block instead of a block.
  TabAtkins: You have to learn that.
  Florian: Or fix it with margin-bottom: -2px :D
  dbaron: If they have a baseline, won't have that problem though.
  dbaron: Only if they fail to have a baseline.
  astearns: So we could resolve on what Tab said, or resolve part of

  <Loirooriol> Hi CSSWG, what about 'block ruby'? The block
               container could establish a BFC.
  <fantasai> astearns actually just asked that question to dbaron,
             didn't get a chance to type it yet :)
  <fantasai> 2nd question was also asked earlier, no answer yet
  <TabAtkins> Loirooriol, It would be rather unfortunate if it was
              impossible to have block-ruby flow around a float;
              there's no reason to restrict that.
  <Loirooriol> Tabatkins, I meant only when 'contain' needs a
               formatting context
  <TabAtkins> Loirooriol, then there's no way to create a block-ruby
              FC without side-effects. :(

  dbaron: I'm okay with resolving but kinda concerned about making
          'contain' even more random
  dbaron: I think one thing that is hard about web dev is that it's
          hard to understand performance effects of things.
  dbaron: Part of why contain is useful is it provides a way to make
          them more predictable
  dbaron: by forcing various types of isolation.
  dbaron: If you make contain less reliable, then you're back to

  fremy: I have a solution but no one will like it.
  fremy: display: none
  fremy: then author will find out it's a problem.
  fantasai: We don't do dataloss by default.
  Florian: Do we also need to stop confusing formatting contexts and
           formatting contexts?
  TabAtkins: Not directly relevant.

  TabAtkins: Thinking to leave 'contain' issue undef for now
  TabAtkins: or figure out something for ruby
  TabAtkins: or say that contain doesn't apply to inline and ruby
  TabAtkins: which do you like best?
  dbaron: I guess I don't feel that strongly.
  dbaron: I think you could say they become inline flow root or ...

  fantasai: I think we imply anonymous containers for ruby
  fantasai: I think if you turn display:ruby into just flow-root you
            will get a flow-root ruby. Ruby does the same thing as
  fantasai: Set display:flow-root on a ruby element you will get a
            block ruby BFC - all boxes needed for ruby will generate
  TabAtkins: You get a contained block and all the performance
             benefits there.
  fantasai: You have side effects like we turn off inlinification.
  fantasai: You have block boxes inside a ruby container they
            inlineify. They won't anymore.
  fantasai: There will be some differences in behaviour...
  fantasai: Actually it would break the case of not using rb elements
            to wrap the bases,
  fantasai: Because the base text's parent is no longer ruby
  fantasai: The scooping algo would not scoop up ruby bases that
            aren't in explicit elements.
  fantasai: So nevermind, I guess that doesn't work.

  TabAtkins: Then let's go ahead and do Loirooriol's thing of having
             "used value of flow-root" terminology for all of our
  astearns: Any resolution for becoming a formatting context?
  TabAtkins: Not yet.
  astearns: proposed resolution to take Oriol's proposal in 1550
  TabAtkins: This is just an editorial change.

  RESOLVED: Accept 1550

  fantasai: Could say that the "becoming a formatting context"
            section is css-contain's problem, remove it from
  TabAtkins: yeah, since it's no longer affecting anything other
             than contain
  TabAtkins: so let's move to 'contain' spec, mark ruby and stuff as
             open issues

  RESOLVED: Move "becoming a formatting context" section back to
            css-contain, mark ruby/inline as open issues to figure

  TabAtkins: Bunch of untriaged issues from Oriol, will talk about
             them later.

CSS UI 4 and appearance
  Scribe: TabAtkins (and fantasai for TabAtkins speaking)
  github: https://github.com/w3c/csswg-drafts/issues/1250

  Florian: There's an 'appearance' property. We started standardizing
           it, because a lot of people use 'appearance: none' on form
           controls to make them styleable in CSS.
  Florian: This previously existed in prefixed form in most browsers.
  Florian: Before standardization, the values other than none was a
           very long list of all the ways an element could look;
           this list was different across browsers.
  Florian: We concluded this was impossible to standardize, in part
           because many apply to pseudo-elements that other browsers
           don't have, as they construct form elements differently.
  Florian: Instead, we'd just have an "auto" value that makes form
           controls look like whatever they need, and a "none" value
           that suppresses it.
  Florian: We could possibly extend this into a small list of
           special values, like "button" to make it look like a
           native button, but so far have resolved not to.

  Florian: Now Mozilla said that they need to implement all of the
           -webkit-appearance values.
  Florian: I'm a little suspicious.
  dbaron: Not sure if that's accurate.
  dbaron: I think it's, *when* we implemented both appearance and
          -webkit-appearance, sites broke.
  Florian: They first said they aliased them to each other, and that
           broke stuff.
  Florian: That's expected, they're very different.
  Florian: They said "we need to implement all the -webkit values
           anyway, so the simple one isn't useful to us"
  dbaron: Not sure that's what we said/meant.
  Florian: Then I'm confused and need to know what they mean.

  <tantek> FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555
  <tantek> see the webcompat.com URLs in the above bugzilla bug

  Florian: "fwiw, we intend to support -webkit-appearance with all
           values that Chrome supports" ~ Mats Palmgren, June 7
  <astearns> comment here:
  dbaron: There are sites that specifically set "input { appearance:
          none; } input[type=checkbox] { appearance: checkbox; }"
  Florian: We did say that, if needed for webcompat, we could add a
           handful of required values.
  Florian: This is very different from adding all 50+ webkit values.
  dbaron: If that's the case, then don't put 'appearance' in a spec
          ready for impl.
  dbaron: Otherwise people try to implement it.
  TabAtkins: Maybe have a scary notice saying this is problematic.
  Florian: I had that note. WG asked me to remove it.
  TabAtkins: I'm fine with putting note back
  TabAtkins: to say that we might need some values.
  Florian: Cool. But that's different from saying we need all the
           webkit values. Because then we need all the webkit
           pseudo-elements, and I'm not speccing that..
  jet: Doesn't mean we might not need it.
  Florian: Maybe, but it'll be a huge effort. Need good proof it's

  TabAtkins: So suggestion: add note saying don't implement this
             property yet; it needs some subset of the
             -webkit-appearance values; impls need to tell us which
             subset is necessary.
  Florian: Initial draft included the other values Edge supports for
           -webkit; presumably that's for compat reasons.
  Florian: WG told me to remove it.
  gregwhitworth: My recollection was a question whether it was even
  TabAtkins: David suggested we did - his example would break
             checkbox rendering.
  dbaron: I don't know the exact details, there's so many bugs and
          compat stuff it'll take a while to untangle.

  Florian: So two options: none | auto | <non-exhaustive-list> ; or
           none | <exhaustive-list>
  fremy: Alternately: let it take any keyword, treat unknown ones as
  Florian: That doesn't match today.
  astearns: Why is "auto" only with non-exhaustive list?
  TabAtkins: We could put it with exhaustive, and we could omit it
             from the non-exhaustive list. Depends on details.
  fremy: If you have "div { -webkit-appearance:button}", nothing
         happens. But "input { -webkit-appearance: none; }" does
         work; using "checkbox" will work on a checkbox input, but
         won't turn a text input into a checkbox.
  <fremy> TabAtkins, yes
  <fremy> TabAtkins, input { -webkit-apperance:none}
          input[type=button] { -webkit-appearance: checkbox }
          renders as a button

  ericwilligers: I heard dbaron say that if they ship appearance
                 it'll break compat. Can we just change the name?
  Florian: And then we can avoid saying "none", and use "normal"
           instead, which sounds better.
  dino: Who implements unprefixed appearance?
  Florian: Nobody that I know, but I last checked a while ago.
  dbaron: We tried, but backed it out before it hit stable.
  dbaron: It's not clear what portions of the problem were with
          "appearance" and which were with "-webkit-appearance".
  dino: I was considering implementing unprefixed with just "none"
        and "auto".

  tantek: One of the points Mats made is that this isn't a
          particularly useful feature for web authors.
  tantek: So one proposal is just to drop it entirely.
  fantasai: People use it a lot.
  TabAtkins: I use "none" plenty to do styles on my buttons, etc.
  dbaron: It's not clear to me which of these was the good reason to
          back the whole thing out.
  dbaron: One of my guidelines is that if a user reports a bug,
          that's a compat problem; if the dev does, that's not
          necessarily a compat problem.
  dbaron: And one of them was reported by a dev, because it comes
          with a jsfiddle.
  TabAtkins: That said, your example looks believable.
  TabAtkins: It would be fixed by fremy's proposal.
  astearns: Would also be fixed by minting an entirely new property.
  astearns: So that seems like a cleaner solution.

  TabAtkins: Possible conclusion, just leave this unresolved, but
             note the handful of possible solutions and ask impls
             to tell us which they want to do.
  Florian: Seems better than trashing it.

  RESOLVED: Put a note into "appearance" saying it's not ready to
            implement, list the possible solutions discussed here,
            ask impls which they want to do.

  <tantek> seems like a lot of work for very little benefit
  <tantek> so I question why
  TabAtkins: Answer to tantek's question is that people use it for
             useful things today
  TabAtkins: and there is no other solution for what they want today.
  <tantek> where is the documentation of the use-case in the spec?
           let's drop a URL here for the minutes.
  <tantek> how high does the cost have to go before it is obviously
           not worth the supposed benefit?

  Florian: Another warning for the spec: the high-level doesn't need
           to change, but details are insufficient.
  Florian: When you appearance:none something, the native-ness goes
  Florian: AND this does not affect its behavior; events still
           happen, etc.
  Florian: This is established.
  Florian: What's not established is: if you "none" a button, does it
           look like an unstyled div, or is there UA styles that make
           it button-y, which you can replace.
  Florian: Another thing: for a range input, you probably can remove
           the graduation on the bar that tells you where you are,
           but you can't remove the thumb; otherwise you have nothing
           to drag.
  Florian: So going from the high-level principles that you need to
           keep it interactive, we need to dive into every control
           and specify what disappears, what is done by the UA
           stylesheet, and what is kept no matter what.
  Florian: If you want me to spend time doing this, say so

  dbaron: I think some impls can assume they always have a native
  dbaron: A number of platforms provide an API that says "draw a
          background of a button".
  dbaron: The original spec didn't say this, but I think both impls
          of appearance were about replacing the border/background
          of a button/widget with a native one.
  dbaron: On some platforms you can rely on these native APIs always
          being present and always working.
  dbaron: On some you can't.
  dbaron: Not sure if we care about those platforms, but we might.
  dbaron: One thing that led us to retain our UA stylesheet is
          because they always existed as fallback, for when the
          platform couldn't draw a native thing.
  dbaron: I think an example was older versions of windows not
          having all the widgets, or Linux themes not always being
  dbaron: At least GTK2, theme might be unable to draw if provided a
          surface that wasn't a real GTK window, so you had to do
          something else.
  Florian: I think this is extra background for what I tried to
           state earlier; a combination of principle and compat
           requirements means that there must be *something* in the
           UA stylesheet.
  Florian: This research hasn't happened.
  dbaron: And specifying border/background explicitly also turns off
          appearance, on most (all?) things.
  dbaron: And there are cases that "appearance:none" also turns off
          *more* things.

  dbaron: FF didn't do this, but WK eventually started doing this,
          so there's lots of weird logic now.
  dino: I don't think there's much we turn off with "none".
  dino: Some cases where you'd get a native widget, but styles
        change it to a non-native widget, so it changes appearance
  dbaron: Some examples: the drop marker in a combo box...
  dbaron: If you say appearance:none, the dropdown arrow next to a
          <select> disappears; setting border/background doesn't do
  TabAtkins: Setting border/background doesn't kill the drop-down
  TabAtkins: But setting 'appearance: none does'
  Florian: And the spec is trying to require that behavior, because
           right now it's unpredictable what will show up.
  Florian: Because you don't know whether it'll be there or not, and
           the pseudo-element varies per browser, when we style it
           with CSS we need to specify what you actually get.
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%20style%3D%22border%3A%20medium%20solid%20green%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22-moz-appearance%3Anone%3B-webkit-appearance%3Anone%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cselect%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22border%3A%20medium%20solid%20transparent%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E%0A%3Cselect%20style%3D%22-moz-appearance%3Anone%3B-webkit-appearance%3Anone%22%3E%0A%20%20%3Coption%3EOne%3C%2Foption%3E%0A%3C%2Fselect%3E

  astearns: This is all interesting, but I"m not sure we need to go
            further into the weeds right now.
  Florian: Yes, I'm planning on putting in a warning for this.

CSS Fonts 4

Which font properties should be reset by the font shorthand?
  github: https://github.com/w3c/csswg-drafts/issues/1636

  myles: Thanks to David, we now have a bunch of correct data.
  myles: [presents it]
  myles: I think there's some consensus that 'font' can reset
         properties that it can't set.
  TabAtkins: It has some "reset-only sub-properties".
  myles: [explains table]
  dbaron: Further question: what's a subproperty of font-variant?
  myles: So should we look for that data too?
  myles: So does anyone outside of dbaron have opinions on this?
  TabAtkins: I think font-synthesis shouldn't be reset, everything
             else I don't care, probably be reset.
  dbaron: My pref is for 'font' to reset the font you specified,
          and not leave a bunch of stuff unresolved.
  fantasai: I strongly agree with Firefox's grouping, except unsure
            about font-kerning.
  myles: optical-sizing should be reset.
  fantasai: Don't know what optical-sizing is, but agree with
            resetting all of those as well.
  dbaron: I think it's important that variation-settings and
          feature-setting get reset.
  [general agreement]

  astearns: Why not font-synthesis?
  TabAtkins: It seems like it's rarely tied to the precise font;
             usually if you care, you'll make sure all your fonts
             have it.
  myles: Same probably applies to font-presentation.
  [general agreement]
  [general agreement that all the others should be; we went thru
      several specific examples]
  Florian: I'm not sure about font-variant
  myles: That's *set* by the 'font' shorthand, it *must* be reset.

  RESOLVED: All font-* properties are reset by the font shorthand,
            except font-presentation and font-synthesis.

  * fantasai still thinks font-presentation is a really confusing
  <fantasai> How about font-iconography?
  <bdc> (agree with fantasai, it's super generic -- just like
        appearance btw)

CSS Counter Styles

  tantek: Yesterday we talked about language of counter-styles when
          read out; we had weak consensus but no strong reasoning.
  tantek: Since then, tab explained to me his reasoning for it being
          defined by the UA language.
  tantek: So we should revisit.
  dbaron: I really don't like making things a function of the UA, as
          that makes a webpage testing problem that most devs are
          totally aware of.
  dbaron: Easy to make things that work fine with an English
          browser, and are strange with a Chinese browser.
  dbaron: Encoding is an example.
  TabAtkins: I agree with dbaron in general, but don't believe this
             falls into that bucket of problems.
  TabAtkins: This is about how to read numeric counter styles
  TabAtkins: when you're in a screen reader UA need to read out in
             numeric numbers.

  fantasai: I don't think that's what it's about.
  fantasai: If you're reading a French webpage in an English UA,
            using alphabetic numbering, the UA will read it as "A B
            C" (english)
  fantasai: Weird to suddenly swap; the rest of the text is
            referring to option A in French.
  TabAtkins: Screen readers are relying on numbers to navigate the
             page, need to have it in their UI language.
  TabAtkins: Mismatch of the text referring to "option ah" and list
             reading out as "list item ay" shouldn't matter because
             the reader understands both languages.
  Florian: I think I can turn your argument on its head.
  Florian: If you're reading a webpage in French, it's unlikely
           that, if it's in French, it would be usable with the
           bullets in English.
  Florian: So having a page of nonsense with a sensible list bullet
           in the middle of it is not useful.
  fantasai: If you're running a screenreader UA, and you always want
            the numeric value of a list, it should have such an
            option to use numeric values regardless of bullet style.
  fantasai: It's a navigation interface at that point; different
  TabAtkins: Relying on page language then is okay, but using
             element's language is not good.
  TabAtkins: Mostly English page with some Spanish text, switches
             numbering, not good.
  fantasai: So this isn't a question for a11y, but i18n. Maybe a bit
            of both.
  fantasai: But mostly i18n people.

  astearns: I have an opinion, but I don't think it's worth as much
            as polling people who use screenreaders with multiple
  fremy: In an English comp, page is in French, even if your
         screenreader can read French, it'll read a button with
         French Text like "<french text> disabled" - speaking
         "disabled" in English.
  fremy: So I'm used to switching; it would be weird if it said
         "disabled" in French.
  TabAtkins: That matches with the "lang of the UA", not page or

  fantasai: Here is the problem I don't want us to have
  fantasai: You have an ebook in French, and your reader is reading
            the ebook
  fantasai: It reads out "Chapitre twenty-three, François va à
  fantasai: rather than "Chapitre vingt-trois, François va à Seattle"
  fantasai: because you used CSS counters and GC to generate the
            chapter numbers
  fantasai: Instead of inlining them into the document source.
  TabAtkins: That's a good example.
  TabAtkins: It seems that goes back to your earlier example of
             navigation being important to read in the UA language.
  TabAtkins: I'm okay with saying that counter styles are read out
             in the element language
  TabAtkins: but adding a note that when reading out numbers as a
             navigation aid, that's part of the UA interface.
  astearns: And both of these things should be read by i18n and a11y.
  fantasai: Right. We'll edit it together, I'll edit Text to have
            the right hook and make sure it's published, and then
            we'll ask for review once we have the prose.
  <fantasai> I think it has the right hook at the moment, just
             hasn't been published in a really long time so we
             can't link to it from counter-styles :)
  astearns: This isn't a requirement for the browser, but for the
  TabAtkins: Right, the browser isn't using it as a navigation aid.

  Florian: Might want an exception for lists - don't want "famous
           authors: one, Steven King; ni, Murakami, ...". Should
           maybe take language from the list instead.
  fantasai: That's bad markup - the list item itself is English in
            this context. If you're marking any Japanese, it should
            be in a span around the name only.
  fantasai: So that just needs more accurate markup; it's not for us
            to fix.

  RESOLVED: same resolution as yesterday
Received on Tuesday, 29 August 2017 21:56:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 August 2017 21:56:46 UTC