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

[CSSWG] Minutes Telecon 2015-11-18 [css-fonts-4] [css-text] [css-grid] [css21] [css-sizing] [web compat] [css-content]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 19 Nov 2015 05:39:46 -0500
Message-ID: <CADhPm3vSBAY0f8s3F3fwKah-gQZtY14LvVd5D-zG0-cOi0r7zQ@mail.gmail.com>
To: www-style@w3.org
max-width and intrinsic sizes in a table scenario
-------------------------------------------------

  - This issue is on dbaron's queue to address.

system-ui change
----------------

  - RESOLVED: Change 'system' to 'system-ui' in Fonts 4

pre-wrap/pre-wrap-auto
----------------------

  - Florian re-introduced his view on the topic, but the right
      people weren't available, so the conversation will continue on
      the mailing list.

Resolve intrinsic track sizes: min-content vs auto minimums
-----------------------------------------------------------

  - fantasai, TabAtkins, and dholbert were deemed the right people
      to solve this problem. They'll respond to the mailing list
      saying they're working on the problem.

Specifying solutions for the generated content issues
-----------------------------------------------------

  - There was a proposal from glazou to take advantage user-select
      to create controls as to if generated content should be
      copy/paste-able.
      - This solution seemed like it would only work for browsers
          implementing multi-range (currently only Gecko)
      - Florian will write a note suggesting to browsers that if
          they do implement multi-range, they should also use
          user-select to create these controls and glazou will
          review it.
  - It was reaffirmed that not all generated content needs to be or
      should be copy/paste-able and therefore the solution needs to
      be a switch. Likely that switch should default to turned off
      for backwards compat.

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

agenda: https://lists.w3.org/Archives/Public/www-style/2015Nov/0256.html

Present:
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Greg Davis
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper (IRC Only)
  Peter Linss
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  Liam Quin
  Florian Rivoal
  Alan Stearns
  Lea Verou
  Jeff Xu

Regrets:
  Rossen Atanassov
  Adenilson Cavalcanti
  John Daggett
  Simon Fraser
  Michael Miller
  Simon Sapin
  Ian Vollick
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  scribe: dael

max-width and intrinsic sizes in a table scenario
-------------------------------------------------

  astearns: Let's start. Not that many people on the call. Does
            anyone have anything additional to bring up?
  astearns: I'll take that as a no.
  astearns: Since dbaron is only here for a bit, let's do 4.
  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0225.html

  astearns: I brought this up because it's interesting and doesn't
            have any answers.
  dbaron: The bug is on my list of things to work on. When I get a
          chance to work on it I'll have a proposal for the change,
          but I don't know the exact conditions.
  Florian: I've looked a bit, but not too much. We're hitting a
           CSS 2.1 undefined where everyone has a different answer
           than Gecko. We'll have to clarify the spec for what
           everyone else does. This is when you have max-width and
           you have a loop where the content depends on the
           container and the container on the content.
  Florian: It seems most people are solving in an intelligent way,
           but Gecko is bailing and resolving in terms of the size
           of the image, not container. It's okay to do, but leads
           to bad results.
  Florian: I don't understand this to any more specific of a level.

  astearns: You mentioned the other browsers do it different. Did
            you test IE or Edge?
  Florian: I don't recall specifically, but I think they're in the
           same camp. I think it's everyone vs. Gecko, but I'm not
           specific on this.
  astearns: Anything else to contribute?
  astearns: As long as it's on dbaron's queue we're fine.

system-ui change
----------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0228.html
  astearns: This is changing the new generic font from 'system' to
            'system-ui' to avoid a problem on windows. jdaggett
            can't be here, but it was his idea. We've heard from
            myles that it's okay.
  * fantasai in favor, too, makes sense
  <glazou> +1
  leaverou: I think it's a bit unwieldy. Maybe 'native' or simply
            something simpler.
  astearns: Given that this is what the system uses for it's ui, it
            seems the shortest that says what it does.
  leaverou: If it's fine by everyone else, I'm fine with it.
  <dbaron> The trick is that it needs to be a single word that
           nobody has ever used as a font name. :-)
  <fantasai> dbaron++

  astearns: Other comments?
  <Bert> +1 to system-ui (unless somebody has a better name...)
  <myles> 👍
  glazou: Totally support this.

  dbaron: One comment for leaverou. The trick is it needs to be a
          single word no one has used as a font name before.
  <fantasai> And having a hyphenated name is actually good for this
  leaverou: And there's no font called system-ui?
  glazou: System-dash-ui, probably not
  astearns: It's not ever, but we have to have one not used by a
            font installed by default. I'm not that concerned that
            there's a font somewhere you'd have to install.
  leaverou: What about 'platform' or 'native'. They're single words
            and I don't think there's a font with those.
  astearns: But going back to have a name that describes what you're
            trying to target. There are tons of native fonts.
  leaverou: yeah...okay.
  <fantasai> I think system-ui is very clear, and because of the
             hyphen, unlikely to cause a conflict
  astearns: Okay, so, I think we're okay to resolve

  RESOLVED: Change 'system' to 'system-ui' in Fonts 4

  astearns: And jdaggett said he'd edit that into Fonts 4 if we
            resolved on it.

pre-wrap/pre-wrap-auto
----------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0239.html
  Florian: I'm not sure this is mine or fantasai or koji. fantasai
           do you want to start?
  myles: fantasai is muted for the call.

  <fantasai> I think the current thread is heading in the direction
             of having pre-wrap only
  <fantasai> and not pre-wrap-auto
  <fantasai> using 'word-break' to get the additional behavior that
             Florian is requesting
  <fantasai> Koji is requesting clarification on use cases on the
             thread, is the last I saw.

  Florian: So in NY after multiple discussions, we resolved to
           clarify the meaning of white-space:pre-wrap into one
           behavior and introduced white-space:pre-wrap-auto to let
           browsers provide what they want which allows nicer
           editing. The specific issue is when there are several
           white spaces. Do we wrap them, let the go long, cut them?
  Florian: This was brought up for two reasons. Every browser is
           inconsistent. None of the solutions solve some of
           Bloomberg's use cases. We made the new pre-wrap preserve
           every space and wrap them.
  Florian: koji doesn't like this, fantasai was re-opening the
           option to drop pre-wrap-auto and allow all the variants
           including what I asked for as the behavior of pre-wrap.
  Florian: I'm not really in favor because I think what I asked for
           is specific and authors want to opt-in. In NY we decided
           that could cover all cases, but I'm okay with going back
           and making it something you opt into. I'm not okay with
           you having no choice what the browser does.
  Florian: If it's an opt-in, what's the trigger and the default?
           One is to say it triggers everything, one is to pick a
           default.
  Florian: I'm not sure we have to repeat the entire conversation
           since we've spoken on this for over an hour already.

  <fantasai> Given my current understanding of the situation, I
             think the best idea is:
  <fantasai> 1. For L3, allow pretty much everything as pre-wrap
  <fantasai> 2. For L4, restrict pre-wrap to not wrap within spaces
  <fantasai> 3. For L4, add a 'word-break: spaces' value to allow
             wrapping at spaces.
  <fantasai> and I agree with the idea of converging on the IE
             behavior for L4, it makes the most sense

  Florian: My proposal is to recommend the IE behavior as the
           default - if you have a series of spaces that goes off,
           you preserve the spaces and they overflow the line.
           Everything else would still wrap. That's D in fantasai's
           e-mail.
  Florian: I would also allow the Blink/Webkit where if you have
           spaces going off the line you elide them. We could also
           allow the legacy spec/Gecko behavior.
  Florian: I don't think that's a great behavior, it's treat the
           entire set of spaces as non-breaking.
  Florian: So, use overflow-wrap: break-word as the default. That's
           what IE is doing in text area elements.
  <fantasai> Florian, you want 'break-word', not 'overflow-wrap'.
  <fantasai> It doesn't fit within the model of 'overflow-wrap'
  Florian: So I'm asking for IE/Edge on text areas with an allowance
           where if you don't opt-in do the Chrome.
  Florian: koji doesn't seem to like that, but I'm not sure why.

  Florian: Does anyone else have an opinion?
  Florian: [reads fantasai comment]
  <fantasai> which only triggers wrapping if the entire line has no
             other line breaking opportunities
  <fantasai> which isn't what you want
  <fantasai> you want to break within the trailing spaces even if
             there's a space earlier in the line
  astearns: Instead of overflow-wrap you want to add the option to break-word
  Florian: The reason I picked overflow-wrap, if you're in IE you
           have spaces overflowing. You could be wrapping in
           different places, but you have spaces overflowing. So
           having the overflow wrap say do break makes sense.
  <fantasai> break-word is the property that alters the
             line-breaking rules
  <fantasai> which is what you're proposing to do
  Florian: If you're falling back on non-IE it still sort of makes
           sense if you think the underlying model is the IE one.

  astearns: It sounds to me like both you and fantasai are looking
            to take the current level and specify here's what
            browsers do, allowing some variation, and locking things
            down in a later level with some options. Does koji agree
            with that start?
  Florian: That's not entirely what I'm saying. The opt-in I'm
           proposing already exists. The overflow-wrap doesn't say
           what you do with a series of spaces. IE and Edge in text
           areas interpret a sequence of whitespace that overflows
           is a place where you can break. I'd rather have that
           wording now instead of introduced later.
  astearns: It sounds like there needs to be a bit more ML
            conversation since koji isn't here and fantasai can't
            speak. I'd encourage you to break this into steps. What
            can you resolve on for the current level and what can
            you put off for the next level that might allow you guys
            to come to a better understanding of each other's
            positions.
  Florian: I'd like to understand why fantasai thinks what I'm
           proposing doesn't make sense, but then maybe what you're
           describing...Yeah. Mailing list time.

  <fantasai> I'm fine to clarify that sequences of spaces may be
             broken for overflow-wrap: break-word
  <fantasai> However *that is not the behavior Florian wants*
  <fantasai> Florian wants to allow breaks within trailing spaces
             *even if there is a line-breaking opportunity earlier
             in the line*
  <fantasai> overflow-wrap does not do that.
  <fantasai> It only has an effect if there are *no* line breaking
             opportunities in the line *at all*

  <Florian> fantasai: "break-word: An otherwise unbreakable sequence
            of characters may be broken at an arbitrary point if
            there are no otherwise-acceptable break points in the
            line." Since we are overflowing the spaces, to me it
            means that there is no otherwise acceptable break points
            for this situation. Making this property appropriate.
  <fantasai> Florian: Nope, you're wrong.
  <Florian> fantasai: :)
  <fantasai> Florian: |xx_xx_|_ has a breakpoint earlier in the line
  <fantasai> Florian: but you want that to wrap

Resolve Intrinsic Track Sizes: min-content vs auto minimums
-----------------------------------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0086.html
  * fantasai has no idea
  astearns: I'm not sure what we can do without fantasai able to
            speak.
  astearns: This is from a few weeks back from someone looking for
            implementor advice. I think we need to do something
            about this.
  astearns: Does anyone have an opinion?
  [silence]
  <fantasai> I think the people that need to discuss this are me,
             Tab, and probably dholbert has a good idea of the
             correct answer :)
  <fantasai> but I don't know at the moment
  <fantasai> Grid algo things really don't work on the telecon until
             at least one person understands the issue.
  <fantasai> and Tab and I tend to batch them up to work on
             together, since we get pretty confused ourselves
  astearns: fantasai says it's her, TabAtkins and dholbert.
  astearns: So one or more of those three should respond on the ML
            to get movement.
  astearns: If that doesn't work, we'll add this to the agenda next
            week.

Specifying solutions for the generated content issues
-----------------------------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Nov/0229.html
  astearns: There's been a lot of conversation and one final message
            where someone linked a bunch of bugs that people have
            filed on browsers.
  astearns: We've talked about specifying some of this or not. But I
            think we should have selection, copy, paste for list
            markers. In our specs you have issues and examples that
            you can't search for.
  astearns: Some people think there should be alt-text, some not.
            But we haven't assigned anyone to put something in our
            spec for this.
  glazou: I think this is very controversial despite the simplicity
          of the technical solution. A long time ago we decided we
          didn't want to copy/paste and slowly we started to allow
          it because people wanted some items. But switching from
          selectables not being able to copy/paste to yes you can
          copy/paste isn't great.
  glazou: User-select lets someone specify how an element is
          selectable. It's implemented by Gecko, Edge, and Webkit at
          least. We could extend this set of properties and apply
          them to pseudo elements to have a thinner control of what
          we can do instead pseudo element. Then we can extend the
          UI stylesheet to specify what is the default for a marker.
  glazou: I'm thinking out loud, but it's a workable solution.
  Florian: First, it kind of makes sense, but will have a problem.
           On the positive side we won't need to work on the UA
           style sheet. It could default to before and after and
           people can switch it on.
  Florian: It'll be a problem because it would work in Gecko, but
           not elsewhere. Gecko has multiple range selections.
  Florian: Other browsers have single range. If you start ::before
           with a user-select it won't work. Unless we say everyone
           has to switch to the multi-range.
  Florian: If we don't have multi-range, it won't work.

  <dbaron> what about selection being built around the range apis
           which are built around the dom which doesn't have the
           generated content in it?

  tantek: The last time this came up, I remember we discussed this.
          I agree with glazou it's controversial.
  tantek: The weak consensus is it's okay to not select copy/paste
          generated content so we can move forward with 2.1
  * glazou 's recollection matches tantek's
  tantek: However I remember we left the door open for browsers to
          think of and try to do a better job because we couldn't
          come up with a better job ourselves.
  tantek: I don't know of any browsers that have done better to date.
          I think glazou's proposal is interesting. I'd encourage
          him to file a bug in bugzilla and say "hey Gecko, please
          consider this enhancement".
  tantek: I do believe that it's within what the standards allow.
          It's not required. If it works we would have a data point
          which we can reason from.
  tantek: There's so much history, I think we need concrete data to
          come to a better decision.
  Florian: It may be a way forward. If the experiment in Gecko is
           successful, how do you think we go from there to apply it
           into other browsers?
  tantek: Dunno. We can cross that bridge if/when we get to it.
  tantek: If we have a next step, we can respond to the list so
          people don't think they're ignored. We can say hey we need
          to try these things to find a way forward. We can also ask
          this person if they filed bugs on other browsers, such as
          Gecko, and let this continue.
  <tantek> note also that the Editing Task Force is working on the
           subject of discontiguous selection
  <tantek> (no I don't have a specific citation, but it was
           discussed in the f2f in Paris)

  glazou: To answer Florian, selection is something that's not out
          of the blue, it's part of the open web platform. There's
          specs in the W3C world that says what it is. Even if
          there's differences between browsers now, we can expect
          interop in the future. The goal of interop is to ensure
          the user experience is the same no matter what.
  Florian: But specs don't exist as a word of god. It's not clear to
           me people will agree to a spec that requires multi-range.
  glazou: I don't care if people won't follow the spec as soon as we
          have two implementations.
  Florian: We have all but one implementation agreeing on something
           else.
  glazou: I know that applying a set of properties to determine what
          we can or can't do with generated content and pseudo
          elements is doable.
  Florian: In the abstract, yes. On user-select, maybe not.
  tantek: I'm leaning more toward what glazou expresses. This has
          been a topic for a long time and we can expect
          implementors to move forward. We can spec that IF you
          support multi-range, here if how you do it, or please
          support this feature if you're doing multi-range. As a
          former implementor, that guidance is really valuable.
  tantek: That's another excellent way forward and a good way to
          test the waters for how appealing that is for implementors.
          If we see people moving toward it, we can start to spec.
          This isn't all or nothing, we can move in glazou direction
          without having to split hairs.

  tantek: There's one argument from Florian I wanted to warn against.
          If everyone but one browser agrees, we can't just decide
          on that. If they're passively agreeing, we can't spec on
          that. That's just specing the status quo, not moving
          things forward. When everyone but one agrees, if the
          agreement is not doing something, that doesn't justify
          specing that.
  Florian: If it works, I like glazou's behavior. I just worry about
           the way forward.
  Florian: In this case, people have said what they want, but maybe
           they'll change.
  Florian: The user-select spec already talks about multi-range.
           Should I experiment at the spec level for text to cover
           this and see if Gecko likes it, or ask Gecko to come with
           language?
  <tantek> sure, make a guideline in the spec!
  <tantek> totally fine to start with informative suggestions like
           that - implementers do read them and use their own
           judgment
  <tantek> it's a good way to test the waters
  <tantek> Note is good
  Florian: So an issue? Note?

  ACTION Florian write a note on user-select for multi-range
  <trackbot> Created ACTION-745

  astearns: Aside from the problems of multi-select, I had a
            question about glazou approach about adding switches to
            change behavior.
  astearns: Is that to avoid problems where people have relied on
            generated content not being selectable, or is there a
            use case for generated content not being selectable? I'm
            wondering about the danger of changing without a switch.
  glazou: We had examples when we discussed it long, long ago.
          People using generated content to do decorations on a
          website and they weren't meant to be selected. It's really
          visual decoration.
  glazou: It's the things that become extremely annoying if you copy
          from a page and paste into a text editor.
  astearns: It seems to be we're trading annoyances. Right now you
            have annoyance where you don't get the list markers you
            want. If we switch you get decorative that needs to
            strip.
  glazou: An example: you have a bulleted list in HTML and the
          bullets can be selected/copied. You copy and paste into
          word and word will paste the bullets. You don't want the
          bullets, you want to hit the bullet button in word. So
          adding the selectable can be good, but it can be bad. It's
          excellent if you want to paste into plain text, but if you
          want to paste into WYSIWYG type editor it doesn't work
          unless you recognize the content.
  glazou: Smart copy/paste is extremely painful.

  tantek: To answer astearns...besides compat danger...the original
          reasoning for why we made that decision was around that a
          lot of us are very afraid that if we treated generated
          content like content it would fail to discourage people
          from putting relevant content there instead of HTML.
          Documents are supposed to be renderable without the
          stylesheet. We wanted to structure to avoid people
          creating problems.
  tantek: In this day and age we're in a very different climate
          where we have all the popular webdevs building websites
          that don't render content without JS. The situation is
          much worse than 10 years ago when we made this decision.
  tantek: At this point, how much harm does it do compared to the
          harm being done with the JS dependency, I don't know. The
          web is worse, I don't know how to fix it.
  <tantek> js;dr reference:
http://tantek.com/2015/069/t1/js-dr-javascript-required-dead

  liam: These days, I don't know why a program like word can't do a
        smart copy/paste. At one timet hat was reasonable, not today.
  glazou: I mentioned word, but it's all word processors.
  liam: And some don't need much fixing. I hear you, but I've also
        been there and talked to impl for things like open office.
        They have shared APIs that help. It's not completely solved.
        We shouldn't rule it out completely. It's much more
        frustrating to have them vanish instead of have to edit them.
  <tantek> also with copy/paste to word (or even google docs) they
           usually use the "HTML" on the clipboard, not the "plain
           text" (with or without bullets)
  <fantasai> tantek++
  <tantek> I tend to agree with the list-marker copy/paste use-case

  leaverou: I think there are use cases for decorative content and
            for real content you want copied or read by a screen
            reader. In printing we use generated content a lot. The
            ship for decorative content has sailed.
  leaverou: Since there are valid use cases for both, why not have a
            property which lets you control if it's decorative?
  Florian: That's glazou's point.
  leaverou: Well, +1 to glazou
  Florian: There are some things not in either camp, but should be
           treated as decorative. Like if you have clearfix
           injecting periods everywhere. So we need a switch with
           off by default.
  <leaverou> it *has* to be off by default, for backwards compat

  glazou: One example. wikipedia. It has unfortunate generated
          content. It has real content in generated content, such as
          geotags. But it also uses it for decorations.
  glazou: Such as images that aren't clickable. So they're using
          both fashions of generated content. The best we can do is
          a switch.

  astearns: As I understand it, Florian will add a note about what
            can be done for browsers that support multi-select.
            glazou do you need an action to propose this switch?
  glazou: I could. The switch is just extending user-select and
          probably one or two more properties to pseudo-elements. [
          audio breaking up] Which I'm not sure if we're doing now.
          If we have that and we explain, we're done.
  Florian: I'd like to write the note first and have you review it.
  glazou: Fine by me.
  astearns: Florian please also respond on the list so people know
            we're listening.
  astearns: Anything else on this topic?
  <tantek> (aside: this topic is a tough one, and the time on it is
           well spent)

  astearns: That's the end of the agenda for the week. So we'll end
            a few minutes early. Thanks everyone.
Received on Thursday, 19 November 2015 10:40:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:34 UTC