W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[CSSWG] Minutes Telecon 2014-07-02

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Jul 2014 11:42:48 -0400
Message-ID: <CADhPm3s1Q-jJ=h8jjTMaL6p5rcJ_Zgxdm7Z994ajjQo38V=-AQ@mail.gmail.com>
To: www-style@w3.org
Re-Chartering Reminder

  - Working group members were reminded to rejoin under the new

CSS3 Text Issues

  - The mailing list proposal to change control characters to
       default display in order to expose these breaks in pages was
  - It was clarified that this proposal would only apply to Unicode
       characters that aren't default ignorable or CSS whitespace.
  - There was general support for the change with most browsers
       expressing support or no opinion. Microsoft requested more
       time, so the intention is to change to default display control
characters pending Microsoft's input.

Flexbox Issues

  - Tab informed the group that the thinking at the last F2F that
       addressing the static position of an abspos child would be
       the same if referencing a box or a point turned out not to be
       correct when using safe alignment.
       - A decision isn't made as to which behavior is better, so
           for now this is purely informational.
  - Tab also requested help in trying to discover how much usage
       there is of flex-basis: auto with a non-auto value for width
       in order to determine how much breakage renaming flex-basis:
       auto would create.
  - RESOLVED: Accept the change to main-size pending usage data and
       future bikeshedding

Selector Parsing

  - RESOLVED: Remove the Unicode range token from syntax and replace
       with a Unicode production similar to <An+B>. Update CSS
       Syntax, CSS Fonts, and CSS Font Loading accordingly.

min/max font-size

  - RESOLVED: Add min and max font-size properties
  - RESOLVED: New ED for Fonts 4

display: contents

  - RESOLVED: Move contents to the display property


  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Adenilson Cavalcanti
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Peter Linss
  Michael Miller
  Shinyu Murakami
  Edward O'Connor
  Matt Rakow
  Simon Sapin
  Alan Stearns
  Lea Verou

  Bert Bos
  Philippe Le Hégaret
  Anton Prowse
  Florian Rivoal
  Dirk Schulze
  Greg Whitworth

  Scribe: dael

Re-Chartering Reminder

  glazou: Let's start
  glazou: First thing, before the extra items, I sent a message
          about the re-chartering.
  glazou: I reminded you that both individual members and invited
          experts must rejoin.
  glazou: You have 45 days or else you're removed automatically.

  glazou: Any extra items to discuss?
  <TabAtkins> Sorry, I was muted a second ago. Agenda+ for max/min-

CSS3 Text Issues
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Jun/0439.html

  glazou: I think there's a message that fantasai sent to the list
          from Jonathan Kew

  fantasai: Basically we have an issue on if we should display
            control characters. Currently browsers don't and this
            message argues we should to expose broken pages and get
            them fixed.
  fantasai: koji and I don't have a strong opinion so we want the
            working group's opinions. If we make the change it will
            require a change to all implementations.

  <leaverou> Isn’t this something that should be defined in the host
  <fantasai> leaverou, no, not really. If the host language wants
             them to go away, it should pre-process them away. CSS
             is what says how text is displayed.

  glenn: Is this proposed as a style property?
  fantasai: We're not proposing it as a style property. We don't see
            a use case for control, this is about the default
  glenn: I would suggest a default of presenting control characters
         is wrong. I think the author could choose to display them.
  TabAtkins: The point of the thread was authors don't want them to
             display, they do it accidentally. You never want
             control characters to display. There's silent data
             corruption because they're left accidentally.
  TabAtkins: If the default stays as don't display, it doesn't solve
             the request and having an author able to choose if it
             displays doesn't help either.

  glenn: For example in Unicode there's many control characters...
  fantasai: No.
  TabAtkins: We're talking about the block of 32 after ascii.
  fantasai: Default-ignorable characters are not affected.
  glenn: C1 controls only.
  glenn: So there's no semantic controls assigned to those?
  TabAtkins: Certainly not on the web.
  TabAtkins: If they were having, them stay invisible isn't great.
  glenn: So I wouldn't object to the C1 characters but it seems a
         special case.
  TabAtkins: It is because all the others are marked by Unicode to
             ignore. These aren't so at the moment by ignoring them
             we're somewhat violating Unicode.
  TabAtkins: Since other parts of the tech stack don't ignore them,
             but browsers do we should help authors realize there
             was a mistake.

  * fantasai wants to hear from browser vendors
  * leaverou wonders how many websites would start looking broken if
             this change goes through.

  glazou: Is there anything else to say about this? I'm a bit lost.
  <koji> I believe his proposal includes C0 too.
  glenn: [reads koji comment]
  fantasai: It includes all the characters that aren't default to
            ignore or CSS whitespace.
  glenn: Is there a default display for C1 control characters?
  fantasai: No, but I think that we would say they must render some
            kind of glyph, be that a missing character glyph or the
            corresponding symbol or what...
  TabAtkins: As an example m-box right now renders C0 as their tiny
             name in a diagonal row across an m-box.
  TabAtkins: Might be a special font. Browsers can have default
             fonts that render or they get a last resort character.
  fantasai: Basically render and be treated as visible for render
            and line breaking.
  <SimonSapin> TabAtkins, Wikipedia uses these separate code points:

  fantasai: Key thing is do we display control characters or
            continue to ignore them? I'd like to hear from browsers.
  glenn: I think we should hear from Unicode or i18n.
  fantasai: Unicode says display.
  koji: I talked to Unicode list and they said we should display in
        identities like URL and says the effects shouldn't apply to
        CSS rendering.
  <koji> http://Unicode.org/pipermail/Unicode/2014-July/000801.html
  fantasai: We're a higher level protocol so we can do what we think
            is appropriate.
  glenn: But if what we think is appropriate is the opposite of what
         they thing, it's worth considering.

  fantasai: Any opinions from browser vendors? Do they need more
            time? Not care?
  TabAtkins: As much as I represent a browser vendor, which is only
             slightly, I'm fine with the change.
  fantasai: Do you want them to display?
  TabAtkins: I'd rather have them display. Or be default ignorable
             so they're ignored by everything. This halfway is no
  fantasai: Microsoft?
  Rossen_: I have to check with the font guy.
  fantasai: Opinions for Apple or Mozilla? Opinions, more time?
  dbaron: Jonathan works for us so I think that's a clear opinion.
          There might be others who disagree with him.
  fantasai: But not you.
  dbaron: I don't have a strong opinion, but tend to agree as long
          as it works.
  fantasai: Anything from Apple or Opera?
  glazou: Apparently not.

  koji: On the Unicode mailing list, opinion was that the spec said
        everything except default ignorable should be displayed
  koji: So if we go and display the discussion might not stop there
        and we'd need more.
  TabAtkins: What else?
  <koji> http://www.Unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
  koji: Unicode says display everything that isn't default ignore.
        If you look at the above url you have the list of default
  <fantasai> http://www.fileformat.info/info/Unicode/category/index.htm
  koji: So characters with glyphs assigned, there'd be plenty to
  TabAtkins: I think we display those in chrome.
  TabAtkins: We do unknown glyphs. Same for FFF. Sometimes there's a
             glyph in the corner.

  glazou: Unless there's more to discuss, I'd like to move on.
  fantasai: My take-away is we'll change it to say control
            characters are displayed unless Microsoft says otherwise.
            Is that correct?
  <fantasai> Since Apple and Opera have no opinion and Mozilla is
             strongly in favor.
  group: Yes.

Flexbox Issues

  glazou: There's 3 in the agenda
  TabAtkins: First item, in the last F2F we thought that phrasing
             abspos text with the position as a point vs as a box
             are equivalent but they're not due to safe positioning.
  TabAtkins: If safe is on there's a difference between where it
             displays with the old text and the current text using
             points to align.
  TabAtkins: In the old text if the box was really big it would
             shift to the side, but now it stays truly centered.
  TabAtkins: This might not be a problem, we're not sure. We're
             bringing up that there is a difference we didn't know
             about before. We plan to review the abspos text in
             general and make it better, so we may review the change
  TabAtkins: We're just brining up that some change may be needed
             and therefore may need approval.

  dbaron: So which way is the text and what's the planned change?
  TabAtkins: We positioned the child as it's the sole item in the
             flex and that gave us a box to position in. The new
             text was that the static position should be a point and
             rephrase in terms of finding a point and aligning the
             abspos to that.
  TabAtkins: Because the old text honored safe align and the new
             text doesn't, we're not sure which way is best to
             handle and which we want to end up with in order to
             make sure it's specified clearly.
  TabAtkins: Right now the only definition is unclear about exactly
             what the static position is.

  Rossen_: So you're suggesting we need to clear up what the static
           position means?
  TabAtkins: I think we'll need to do that unless fantasai included
             a simpler approach. It's a 'hey we'll need to revisit
             this as we narrow things down' statement.

  TabAtkins: Next issue.
  <fantasai> This is the issue :
  TabAtkins: This needs discussion. We discussed that flex-basis:
             auto is odd because it overlaps with width so you have
             to say flex-basis: auto and width: auto.
  TabAtkins: It's also weird that computed and used values of auto
             mean something different.
  TabAtkins: We discussed re-naming flex-basis: auto. We
             provisionally are using main-size
  TabAtkins: We're leaving the short hand as is because it's used
             too widely.

  TabAtkins: So is the name change okay and does anyone have the
             ability to track what the actual usage of flex-basis:
             auto is and if it's paired with non-auto width?
  TabAtkins: Right now chrome is showing a disturbingly high number
             of uses. I think a lot of tutorials ignored our note
             not to use. Hopefully there isn't much paired with non-
             auto width because that's the real problem.
  TabAtkins: If anyone has a way to track this, that would be
             awesome and, if not, we might just make the change and
             see how much breakage there is.
  TabAtkins: Any thoughts or suggestions on a better name than
  <dbaron> I'm happy with the change assuming it sticks.

  Rossen_: This is in the current ED?
  fantasai: Yeah.
  Rossen_: I was looking at it and...
  TabAtkins: Do you see it now?
  Rossen_: Yeah.
  Rossen_: That sounds pretty good.
  TabAtkins: Okay.
  TabAtkins: If there's no objections for now we can stick with it
             and if someone comes up with a better idea, post to the
             ML thread.

  Rossen_: So, to clarify, you see a bunch of flex-basis usage, but
           can't track values?
  Rossen_: I'll see if I can run a query.
  TabAtkins: If you can, check to see if you can find flex-basis:
             auto paired with a non-auto width
  TabAtkins: It would be good to know how much flex-basis: auto
             there is, but we also what to know how much will change
             when we say it's actually auto, not to look at width.
  Rossen_: Is this a change fairly soon?
  TabAtkins: We just changed the spec yesterday. There's no
             implementations yet.

  fantasai: The other name option was match-size.
  TabAtkins: I didn't like it because it seemed to imply that it
             should look at another element, but it's not a strong
  Rossen_: I think main-size is good. I'm sure there will be a lot
           of action once we get close to another round of calls.
           Then we'll get 10 other names.
  fantasai: Seems people are happy with the general content.
  Rossen_: Yes.

  fantasai: So resolve accepting the change pending usage data and
            future bikeshedding?
  glazou: Any objections?

  RESOLVED: Accept the change pending usage data and future

  glazou: Next one?
  TabAtkins: Next is fantasai or dbaron?
  Rossen_: There's another flex?
  TabAtkins: No, there were just 3 links, but 2 topics.

How far from bases should ruby text be?

  fantasai: dbaron do you want to do this on the mailing list?
  dbaron: Yeah, let's discuss on the list.
  glazou: gregwhitworth sent item 4, but sent regrets, so I think we
          should move to item 5 for now.

Selector Parsing
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Jun/0486.html

  TabAtkins: The issue is that the Unicode range token we just
             discovered has a long running source of potential bugs.
  <TabAtkins> div u+a { color: red; }
  TabAtkins: Okay, pretend that was a real color.
  TabAtkins: This is looking like div with a decedent and a sibling.
             This parses as a div ident,
  TabAtkins: And then a white space,
  TabAtkins: Then a Unicode range token with the value a.
  TabAtkins: This happens any time you have an underline tag
             selector followed by a sibling combinator followed by a
             through f.
  TabAtkins: So the selector will be invalid accidentally.

  glazou: So does that mean current browsers fail?
  TabAtkins: Chrome and Firefox at least call that invalid, IE does
             not. Selector parsing is defined loosely. At least 2
             browsers consider it invalid.
  TabAtkins: This is with CSS minifiers that removes space around
             combinators except in this one case.

  TabAtkins: The suggestion is to fix this by killing the Unicode
             range and instead use something like <An+B>.
  TabAtkins: It'll be just as ugly and complex, but we know it's
             possible and you can't put one together that works.
  TabAtkins: I think this is the right way because it's an odd
             parsing case that doesn't look like anything else in CSS
  <SimonSapin> +1
  <fantasai> I am strongly in favor of doing this.
  <fantasai> Unicode-range is only used in one place in the entire
             language; shouldn't be causing problems anywhere else.
  TabAtkins: I can see how special purpose tokens can cause problems
             here or in the future.
  TabAtkins: So I say we replace with a production and make sure the
             two specs that care, font and font-loading, get updated
  fantasai: I think this is a good idea.
  TabAtkins: Some people on thread seem okay with it, but I want to
             hear objections.
  <leaverou> +1 for the change

  glenn: Do you have a concrete proposal for replacement syntax? You
         said something like <An+B>, I was wondering if you have
         actual proposal.
  TabAtkins: I have it in my head, but not in the spec. If I have
             difficulties I can bring it back to the list.

  fantasai: We have people in favor. Anyone not?
  <bkardell_> +1
  <glenn> +0
  glazou: I'm in favor.
  dbaron: It seems like a bunch of work to implement so we may not
          do it immediately and may do a patch and later do it the
          right way. It's easy to fix doing context-dependent.
  TabAtkins: It's easy with implementations, but I'm for solving it.
  dbaron: Context-dependent tokenization is worth avoiding in the
          long run.

  RESOLVED: Remove the Unicode range token from syntax and replace
            with a Unicode production similar to <An+B>. Update CSS
            Syntax, CSS Fonts, and CSS Font Loading accordingly.

  glazou: That was shorter than expected. Rossen_ can you do
          gregwhitworth's item?
  Rossen_: I think TabAtkins was saying he has something to say.
  TabAtkins: I have an agenda+
  Rossen_: So let's do that and if we still have time I'll talk.
  * fantasai also has agenda+ for display: contents

max/min font-size

  TabAtkins: I think this is a reasonable request, such as when I'm
             doing a large text and want it bigger but not bigger
             than the screen. It should be sized in viewport units,
             but not larger than the viewport.
  TabAtkins: It seems reasonable, but I'm wondering if there's issue.
  TabAtkins: There's a min and max property and you resolve in the
             same way max and min are done. If it violates max,
             resolve and if it violates min resolve again.
  TabAtkins: So in my case if you want really big text, but not have

  <leaverou> {min,max}-font-size have been requested quite a lot by
  <tantek> copyfitting!

  fantasai: I think this is reasonable to have. The only alternative
            is if we introduce max and min functions so you can put
            it inline.
  fantasai: I agree with solving with either the property or the
            max/min functions.
  TabAtkins: They're not incompatible. We could always add the
             second later.

  dauwhe: Is there an accessibility concern?
  TabAtkins: I think the opposite. Min font size can be useful so
             that whatever fancy units you use, you don't get
             smaller than 15 px.
  dauwhe: It sounds like this could help the ebook world.

  TabAtkins: So are there any objections or any reasons why we
             haven't adopted this besides the possible duplication?
  <hober> max-font-size: 80vh; min-font-size: 12pt;
  MaRakow : I'd be interested in seeing how we're supposed to use it.
            So min size is so it stays readable, but you're
            resolving on max?
  TabAtkins: Min wins all conflicts. That matches existing
  MaRakow : If you're doing the example from hober, 12 would be
  fantasai: You use the font-size property to set the font size and
            this places a limit.
  MaRakow : So you use all three in combination?
  fantasai: Yes. You set min max on the document and use font-size
            to set the font size throughout the document, knowing
            that and know that when you set the font it will never
            go above or below your min/max.
  TabAtkins: Keeping the same semantics as min/max width seems
             sensible. Max prevents overflow and min prevents
             unreasonable smallness so, for accessibility, honoring
             min when it conflicts max is sensible.

  <tantek> do we have font-size:auto yet?

  TabAtkins: fantasai, do you object to the property, or want to
             give another try to functions?
  fantasai: No, it makes sense. You may want to do things
            separately, so separation gives better usability
  TabAtkins: Cool.
  TabAtkins: So any objections?

  RESOLVED: Add min and max font-size properties

  <tantek> nice - well done all

  TabAtkins: Is John still fonts editor?
  glazou: He asked to leave the working group temporarily.
  TabAtkins: Then I can do editing.

  fantasai: Fonts is in CR so do we add to 3 or 4?
  fantasai: I think the syntax should be level 3, but this is a new
            feature. Maybe toss it in an ED?
  ??: Elsewise we'd have to go back to LC?
  TabAtkins: Yes, until we remove LC as a level.

  TabAtkins: So I will add the properties to an ED that I will start
             and whenever we made the edits, we'll make sure they
             happen on the Fonts 3 CR. If we do this right, it'll be
             an informative change.
  glazou: So if there's a new ED, we need a resolution. Any
          objection to starting a new ED for Fonts 4?

  RESOLVED: New ED for Fonts 4

  <tantek> new ED, implementations, test cases, interop, slip it
           into a Fonts CR iteration
  * fantasai thinks she agrees with tantek in this particular case,
             it's a slight enough addition

  glazou: I guess that closes this issue. Anything in the last 9

display: contents

  <fantasai> mail describing the issue:
  fantasai: TabAtkins and I were discussing this and TabAtkins
            brought up we have display-box that takes none, normal,
            and content. The purpose of splitting was to create a
            dedicated switch for turning visibility on/off.
  fantasai: This violates that goal. So it's the same problem as
            with the display. So the proposal is to move content out
            of display-box so that it's just about hiding or showing
            since that needs to be a separate switch.
  fantasai: Especially since contents is separate of display type.
  TabAtkins: None also belongs, but there's reasons to leave it. So
             this is so we can have an item hidden and can easily
             toggle without having to know everything about it.
  TabAtkins: We think it would be okay so that whatever property is
             holding display: none can have multiple items hidden.
             Right now we have display: none that prevents from
             displaying, and another where it hides, but makes it
             create them for the purpose of counters and the like.
  TabAtkins: We think we can do multiple hiding properties and one
             shown and still get away with the use case.
  fantasai: I think you don't want multiple for hiding, but for this
            discussion, this is just moving contents into the
            display property.

  TabAtkins: Display is a ED until I finish the edits I was supposed
             to make in January. Since we're going to publish a WD
             it should be approved
  <fantasai> TabAtkins, display module is already fpwd
  <fantasai> www.w3.org/TR/css-display-3/

  glazou: I don't want you to perceive and receive this as a flame,
          but I have a feeling this goes far beyond what web authors
          will understand.
  glazou: I'm not saying we don't need the feature, I think we are
          reaching levels of complexity in our solutions that are
          beyond the users ability.
  glazou: I think we need to think more and find something more
          usable and readable.
  dbaron: About what?
  glazou: All the display-* properties
  fantasai: This is taking a value out of a property that's
            basically show or don't show the box. That's a clear
            switch that authors want and it needs to be separate
            from the box display type.
  fantasai: We're asking to put it back into the display property.

  Rossen_: When you say show/don't show, you mean affect or don't
           affect the layout?
  TabAtkins: This is the display: none value pushed into a separate
  Rossen_: But it still computes those things inside?
  TabAtkins: The normal is no behavior change. We think we can add a
             value that does compute inside and just doesn't display.
  Rossen_: It's pretty hacky.
  fantasai: That's not what we're discussing now. The issue is we
            have a property in a WD that takes these three values.
            It's show or don't show the box, but it has a value
            that's a display type. That should be in the display
            property. We want to move it from the 'show/don't show
            the box' property to the 'this is how we display'
  fantasai: I just want a resolution on that. We can discuss the
            rest later.

  TabAtkins: So does anyone object to moving the contents value?
  TabAtkins: Sounds like not .
  Rossen_: It's probably okay. I'm sure we'll revisit.
  fantasai: Anyone else?
  fantasai: You all just really don't care?
  Rossen_: It's time so people want to go away.
  TabAtkins: It's a time-out.

  fantasai: So do we resolve?
  glazou: No objections?
  Rossen_: Doesn't sound like there's support or objection.
  glazou: Yes.
  Rossen_: I don't see why we'd block keep on working. It sounds
           like they're still going on that spec and we'll be
           discussing it again.
  glazou: That's a suggestion to defer?
  fantasai: I'd like a resolution that content goes on display or
            display-box. We have it in the WD and people are
            apparently implementing this, according to the last F2F
            discussion, so does this go to display or display
  SimonSapin: The proposal sounds good. To move it to display

  glazou: Objections?
  glazou: Support? Comments? Everyone can live with it?
  Rossen_: For the time being.

  RESOLVED: Move contents to the display property

  glazou: So this is the end of the call. Thank you and bye
Received on Thursday, 3 July 2014 15:43:16 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:42 UTC