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

[CSSWG] Minutes Sydney F2F 2015-02-10 Part II: CSS UI

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:48:43 -0400
Message-ID: <CADhPm3vN8CwXDRM1N=9Pf8f1f906xwp2t6CfTjBYu=y_oV+v8Q@mail.gmail.com>
To: www-style@w3.org
CSS UI
------

  - RESOLVED: Spec resize property to inject 'width/height' style
              attr values in pixels, because we have interop and
              nobody wants to make it better.
  - RESOLVED: Auto cursor switches between default/text whether
              you're over text. No other magic.
  - RESOLVED: Don't specify anything for how outlines actually work
              other than what's there already. More details in next
              level.
  - RESOLVED: Resize doesn't apply to pseudos. Note that this may
              change in the future.
  - RESOLVED: Leave spec as-is, don't apply text-overflow when
              overflow: visible.
  - RESOLVED: Drop wording allowing word-drops, add as a new feature
              in L4 e.g. as a new keyword or something.

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

CSS UI
======
Scribe: fantasai

  <tantek> https://wiki.csswg.org/spec/css3-ui#steps-to-pr
  tantek: In pretty good shape with CSS UI.
  tantek: The links is a set of steps to get to PR.
  tantek: We're down to about 7 semi-substantial or substantial
          issues, resolutions on most of them.
  tantek: Steps to PR, we've got a set of drafts to publish, one
          queued up.
  tantek: Fixes to issues at this meeting.
  tantek: Interest in test cases? Spec is probably stable.
  tantek: Features are stable. Ee're cutting things, not adding
          things.
  ChrisL: Couldn't run the first test,
  ChrisL: for directional navigation.

  fantasai: I would like to see a WD of what you think should be
            going to CR, i.e. after you've fixed the outstanding
            issues, and then request a review of that. You haven't
            demonstrated wide review of the thing you're proposing
            for CR.

  <tantek> Current issues: https://wiki.csswg.org/spec/css3-ui#current-issues

Resize Property (Issue 47)
--------------------------

  <tantek> https://wiki.csswg.org/spec/css3-ui#issue-47
  tantek: Issue 47
  tantek: Objection from TabAtkins to resolution, +1 from smfr
  [tantek summarizes the issue: original spec talked about a "resize
          factor" that was maintained implementations instead modify
          'width/height' inline styles directly]
  tantek: The downside of speccing that is that it limits how you
          handle e.g. resizing of the window by the user.
  tantek: You rob the author and user of having interfaces that
          dynamically resize in a sensible manner.
  tantek: Resolution at last telecon was to change "factor" to
          "function"
  tantek: and allows for more intelligent resizing.
  tantek: The point here is to not restrict the web platform in ways
          that prevent it from being competitive with native
          platforms.
  tantek: That's the goal of sticking with the function wording,
          rather than artificially restricting to style attrs.

  Florian: Current behavior with browsers does fall short where we
           could do better.
  Florian: I disagree that the function is a good way to solve this,
           because it's so generic, better ones and worse ones,
           could be conformant.
  Florian: Also, I think it's reasonable to spec in a detailed way
           what is currently implemented, but also to extend it.
  Florian: e.g. say "resize me, but do so in percent, rather than in
           pixels" or "resize me in ems rather than in pixels".
  Florian: The function that you allow is undefined, which is good
           because it allows good behavior, but is also bad because
           it also allows bad behaviors.
  Florian: Would rather spec what browsers are actually doing, and
           allow extending.
  <SimonSapin> +1 Florian
  <glazou> dino also said +1
  <AndreyR> +1
  <dbaron> I think the underlying problem with 'resize' is that the
           feature was specified at the wrong layer of the platform (
           too low).

  fantasai: What would would be worse than the current behavior?
  Florian: ... not interoperable.
  fantasai: So your issue is that non-interoperable is bad. I'm
            asking, what is a specific behavior that is worse than
            the current behavior? Because I think the current
            behavior is the worst that I can think of that isn't
            pathological (e.g. semi-random output on resize).

  dbaron: I think the underlying problem with this feature is that
          it was designed at the wrong layer of the platform.
  dbaron: Was trying to hook into low-level CSS width functions what
          should have been a higher function.
  dbaron: It's a lot of work for something that shows up in
          high-level controls
  dbaron: Implementations proxy it down to a lower level, using what
          authors could use to do it.
  dbaron: They reuse their existing code rather than changing
          width/height computation for everything else in their
          codebase.
  dbaron: We have a legacy feature.
  dbaron: We should just spec it better,
  dbaron: And figure out a better way to have the feature that
          doesn't go poking in low-level CSS calculations.
  tantek: The intent was to keep it high-level from the start.
  tantek: That's how it started, trying to specify purely as a
          high-level feature, not imposing at all on how
          implementors implemented it.
  tantek: The factor was a possible case, generalized to function.
  tantek: There seems to be that even that is specifying too much.
  TabAktkins: Not specifying enough.
  tantek: Goal was to make this a high-level feature for authors.
  tantek: Not sure what different approach could be taken.

  Florian: What we have now is extensible.
  tantek: By specifying new values.
  fantasai: The default behavior would still be the stupid behavior,
            that doesn't resize well. Even if you add more keywords,
            the number of people who use it would be negligible.
  fantasai: That makes it not worth adding the new keywords.
  tantek: Should do the right thing by default.

  Florian: I have wording for the current interop behavior.
  Florian: Blink and Webkit differ from Firefox in a couple cases.
  Florian: I propose to spec this and see if anyone disagrees,
  Florian: built up from tests.

  zcorpan: When and if we do come up with a successor of this
           feature, that can provide better behavior
  zcorpan: I think it is good to not let the different browsers
           choose different behaviors for the same request from the
           authors.
  zcorpan: It's bad if for example one browser uses pixels and other
           uses percents.
  fantasai: The author doesn't notice any problems or differences in
            behavior because they're designing in a single size.
  fantasai: The differences in behavior only show up when you resize
            the window.
  tantek: Resizing the window is pretty common *rotates his phone*
          This is resizing the window.
  TabAtkins, florian: You just resize it again.
  tantek: If the screen gets narrow I can't get to the resize handle.
  TabAtkins: scroll and resize again.
  [basically user has sucky experience because we have interop, and
             we don't give a shit]
  tantek: You want to make the poor behavior a must?

  fantasai: So I don't understand the suggestions to create a new
            feature that does better.
  fantasai: Either you are happy with the existing behavior, or you
            want a better behavior.
  fantasai: If you want a better behavior, you could do it by adding
            a new feature, or you can do it by improving the
            existing one.
  fantasai: The only reason to create a new feature rather than
            improving the existing one is if you have a legacy
            problem.
  fantasai: I don't think we have a legacy problem here.
  [...]
  TabAtkins: Floating first letter is an example where we had bad
             behavior, couldn't improve it, so made new feature.
  tantek: Did design methodology change?

  ChrisL: 'Must' is what you should say in all cases where you know
          what is the right thing to do.
  ChrisL: 'Should' allows you to not do that if you have a good
          reason, but good reason is not defined.
  SteveZ: 'Should' was being used often in cases where there was not
          interop, and we didn't expect interop in the timeframe of
          getting the spec out, but there was at least one version
          that people could match over time to get interop.
  SteveZ: So we used 'should' in context of saying, you're not going
          to be an invalid implementation just because of the fact
          you don't match it now, but this is where we want people
          to be going.
  tantek: So if there was in implementation of resize of good
          behavior, we could put a should.
  SteveZ: Yes, and we could spec that particular one as a should.
  fantasai: And we used 'may' in cases where we didn't have an
            implementation, but we knew which direction we wanted to
            go to.
  tantek: My memory agrees with what SteveZ was saying.
  tantek: I'm okay with speccing style attr in pixels, since nobody
          shows any intent to make it better.

  RESOLVED: Spec resize property to inject 'width/height' style attr
            values in pixels.

  <dbaron> I guess my opinion about it being badly designed might
           not be as strong as it was 10 minutes ago, after looking
           at our code.
  <dbaron> though I still don't know how resizing the old way would
           interact with something like flexbox
  <dbaron> (old way being as a resize factor)

cursor: auto (Issue 48)
-----------------------

  <tantek> https://wiki.csswg.org/spec/css3-ui#issue-48
  Florian: cursor: auto is vaguely defined.
  tantek: We had a group discussion on auto cursor, to try to
          restrict auto value as much as possible.
  tantek: Define specifics instead.
  tantek: Issue is about resize areas and scollbars.
  tantek: The proposal handles this, but may need additional wording.
  Florian: dbaron's original proposal of switching between switching
           between text vs. default
  Florian: Either out of scope for CSS, or expressible in a UA style
           sheet.
  Florian: We decided that resize cursor for the resize handler is
           an override over whatever cursor value that author chose,
           not specific to auto.
  Florian: You can do magic over links for auto, but don't have to.
  Florian: The only thing that needs to be magic inside auto is text
           vs. empty space.

  ChrisL: Should we have some way to know whether you're empty space
          or text?
  tantek: Don't have a way to detect scrollbars or resize handlers
          either.
  Florian: We don't have a ::cursor pseudo.
  ChrisL: So proposal is to have auto switch between 'default' and
          'text' based on whether you're over text?
  tantek: And 'text' already handles horizontal vs vertical text
          cursors.
  ChrisL: What about links?
  Florian: You have a UA style rule for that.

  zcorpan: If you specify auto on a link, then you get a text cursor
  zcorpan: html style sheet requires UA to specify pointer on links.
  tantek: Possible regression if people have written * { cursor:
          auto; }
  Florian: Matches what firefox does, webkit does more magic.

  RESOLVED: auto cursor switches between default/text whether you're
            over text. No other magic.

Outline (Issue 55)
------------------

  <tantek> Issue 55: https://wiki.csswg.org/spec/css3-ui#issue-55
  Florian: Simple cases, everyone understands outline, but aside
           from that there's no interop,
  Florian: Not possible to spec it all in Level 3 timeframe.
  tantek: In some cases we can't spec.
  Florian: Would like group to sanction having a very loose spec for
           outline in L3.
  <AndreyR> agree
  Florian: And clarify in L4.
  Florian: For example, what do you do if element is transformed? Do
           you transform the outline or not?
  Florian: If children overflow, do you extend outline to include
           them? Is the outline a rectangle or weird shape in that
           case?
  tantek: Contrary to resize, this is a feature where we've seen a
          lot of innovation in browsers.
  tantek: It is an area that is so diverse that we don't want to
          pick any favorites right now, because we don't know how to
          specify those.
  tantek: We've seen some nice stuff, and want to see what the
          market comes up with.

  tantek: I suggest issue 55 and 51 close as no change.
  fantasai: I agree with closing 55.
  Florian: 51 is transforming outline.
  fantasai: If you have interop on something you don't want, then
            need to speak up about it.
  <AndreyR> no obj
  [...]
  Florian: Need to answer question of whether outline is supposed to
           be a focus indicator or a border that doesn't take up
           layout.
  fantasai: Whether it rounds on radius, what is its z-index.
  fantasai: I'm concerned that if you don't deal with this now,
            you'll end up not having a choice.
  fantasai: You need to address the transform issue,
  fantasai: must do it now or it's too late.
  fantasai: Do we want to transform the outline or not?
  fantasai: I would like to know what other people think, because my
            opinion is completely worthless here.
  dbaron: If you're in a 3d scheme, there isn't necessarily a decent
          definition of what area is covered by your children.
  Florian: If you want outline to be a focus indicator, you put
           outline around the projected result.
  Florian: We haven't specified this.
  dbaron: I Think we can't specify now.
  tantek: Objections?

  RESOLVED: Don't specify anything for how outlines actually work
            other than what's there already.

Resize on Pseudo Elements (Issue 52)
------------------------------------

  <tantek> 52: https://wiki.csswg.org/spec/css3-ui#issue-52
  tantek: No interop on pseudo-elements.
  tantek: Suggest to say that they don't apply to pseudo-elements.
  Florian: I don't think you can say that it does not apply and then
           make it apply later.
  dbaron: What we do is say the applies to line, and then have a
          note saying that in the future we might extend things.
  tantek: The proposal is resize doesn't apply to pseudos, and add a
          note that it may apply in the future.
  fantasai: Wouldn't say where it's going to be solved, just say it
            may be solved in the future.

  RESOLVED: Resize doesn't apply to pseudos. Note that this may
            change in the future.

Applying text-overflow when overflow: visible
----------------------------------------------

  <tantek> https://wiki.csswg.org/spec/css3-ui#issue-68
  Florian: Initial version of text overflow required overflow
           ~= visible and line would overflow its containing block.
  Florian: This is unfortunate if you have a float in the way. You'd
           overlap the float.
  Florian: The spec is changed to elide before the float.
  Florian: Which is what Webkit does.
  tantek: Suggestion to request that text-overflow apply even when
          overflow is visible.
  <tantek> I think generalizing to regardless of overflow value is
           too big of a change.
  rossen: That's problematic.
  rossen: What would a block with text-overflow: ellipsis report for
          its main content size, if all lines are ellipsized?
  fantasai: text-overflow does not affect sizing.
  [...]
  Florian: What was specced was Firefox's behavior. now specced
           webkit's behavior.
  Florian: Firefox also asked for not requiring the overflow rule.
  tantek: We don't have an implementation yet, though.
  <AndreyR> agree with Tantek
  fantasai: The main concern I have with the overflow issue is web
            compat.

  RESOLVED: Leave spec as-is, don't apply text-overflow when
            overflow: visible.

Reverting text-overflow ellipsing at a line break
-------------------------------------------------

  <tantek> https://wiki.csswg.org/spec/css3-ui#issue-76
  tantek: Request made over twitter to allow implementations to
          ellipse for text-overflow not at a character break
          boundary but at a line break opportunity.
  tantek: Seems like a reasonable request, not sure if anyone would
          ever do it, so I put it in as a may.
  tantek: One request to revert it.
  tantek: Text-overflow, when you get to point where it overflows,
          instead of clipping you back off the number of characters
          to have ellipsis and not partial characters.
  tantek: Proposal is to ellipse at a word boundary, line-wrapping
          opportunity.
  dino: We would do that, ellipse at a line-wrap opportunity

  Florian: I have a few problems with these problems.
  Florian: What looks better depends a lot on the context.
  Florian: If you're in a mixed directionality context, starting
           English, Hebrew going the other way around. Now what
           exactly are you doing? You don't want ellipsis in the
           middle of the line.
  TabAtkins: Ellipsis is visual.
  Florian: Another issue is do you know enough about wrapping
           opportunities to do it at the visual layer when you're
           doing the ellipsis.
  Florian: Another issue is scrolling. If you scroll, it's supposed
           to reveal more content as you go.
  Florian: The really weird to drop in words as you scroll.
  tantek: Behavior for scrolling is already looser than wording for
          not scrolling.

  fantasai: I disagree with this change, if you want this change it
            should be a separate property and/or keyword
  fantasai: to allow ellipsing at a word / line-wrap opportunity.

  RESOLVED: Drop wording allowing word-drops, add as a new feature
            in L4 e.g. as a new keyword or something
Received on Wednesday, 18 March 2015 21:49:14 UTC

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