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

[CSSWG] Minutes Telecon 2016-08-24 [cssom][css-logical-props][css-values][css-ui][css-images][css-masking][paint][css-text-3][cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Aug 2016 21:28:03 -0400
Message-ID: <CADhPm3td07AODYZD5EEx2k7_N=ph4Vd4Z48t1j++moK-bimYsg@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.

Resolved Value of Logical Properties

  - RESOLVED: Add text to CSS OM and to Logical Properties as
              proposed (logical properties take their CSS OM
              behaviors from their physical equivalents)

Add <number-optional-number> type

  - Rossen requested a week to review.

user-select: none and selectionchange event

  - Florian will reach out to the editing task force for feedback.

  Ambiguities in handling url()

  - This topic was deferred to TPAC.

Algorithm of `Element.offsetParent`

  - This topic was deferred to next week.

Segment Break Transformation Rules for East Asian Width property of A

  - astearns will reach out to the Internationalization group for

Value is used value?

  - Florian will investigate having two user-select properties, one
      of which is a shorthand for the other. If that seems to work
      he'll also investigate if there's a reason to expose the
      longhands to the author.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0066.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Brian Kardell
  Ian Kilpatrick
  Peter Linss
  Thierry Michel
  Michael Miller
  Anton Prowse
  François Remy
  Florian Rivoal
  Geoffrey Sneddon
  Jen Simmons
  Alan Stearns
  Liam Quin
  Greg Whitworth

  Tantek Çelik
  Dael Jackson
  Myles Maxfield

Scribe: Liam

Resolved Value of Logical Properties

  astearns: Extra item: weekly reminder to add things to the TPAC
            agenda, and register etc

  <astearns> https://github.com/w3c/csswg-drafts/issues/384
  fantasai: Do we use return the used value or the computed value?
            My suggestion would be to keep it equal to the physical,
            as if they are aliases to the same property
  * glazou tends to agree with fantasai
  Rossen: When you have e.g. vertical direction, what would you
          return for width vs logical property?
  fantasai: For width, if it was specified in percent you'd return
            it in pixels. The question is what do you do for
            getcomputedStyles for the block size/inline property, in
            pixels or computed value? And I'm arguing it should
            behave the same, the used or the computed value as
            determined by its physical equivalent.
  <Florian> +1
  Rossen, OK, agreed

  astearns: Is this going to go into CSS OM spec? or gets added to
  fantasai: I think a blanket statement in the CSS OM.
  Rossen: Perhaps we can add something to the CSS logical properties
  plinss: Are there any examples of properties that would flip,
          width vs height based on block direction for example?
  fantasai: No, I don't think so.
  plinss: The only difference I care about is if you're returning
          the used vs computed value, and wondering if that's going
          to change based on which physical property the logical one
          will resolve to. [but sounds like this is not the case]

  RESOLVED: Add text to CSS OM and to Logical Properties as proposed
            (logical properties take their CSS OM behaviors from
            their physical equivalents)

Add <number-optional-number> type

  <astearns> https://github.com/w3c/csswg-drafts/issues/385
  fantasai: [introduces the issue] e.g SVG has a lot of lists that
            continues, we could add a multiplier #
  <TabAtkins> Basically, for a *pair* with optional commas, do:
              <one> ,? <two>
  <TabAtkins> For a list with optional commas, do: <item>+#
  <TabAtkins> This is not something we'll ever do for CSS itself;
              this is just translating some legacy SVG syntaxes to
              CSS properties.

  astearns: If what people want to express is already expressible in
            the grammar I'm not sure adding more is here we want to
  fantasai: [missed] proposal is to add +#
  fantasai: In order to be able to express some SVG syntaxes that we
            do not propose to use for anything new.
  Rossen: Is this request from the SVG WG?
  astearns: Yes, filter effects module started the issue; nikos in
            favor of adding it.
  Rossen: I'd want to go back [and review this request in more
          detail] and see if it's worth the complexity.
  Rossen: Don't think it's pressing
  Rossen: can we move it to next week?
  [fantasai, Tab, Ok with this]

user-select: none and selectionchange event

  <astearns> https://github.com/w3c/csswg-drafts/issues/319
  Florian: What happens if you click in a user-select: none area and
           there's already selection? What if you drag there? Varies
           between UAs today.
  Florian: You don't get an event in Firefox and do in Edge and
  <dbaron> The behavior of unselecting on click seems to make more
           sense to me.
  <dbaron> (Was that Edge and Safari?)
  glazou: I suggest we normalize the behaviors; I tend to think the
          Firefox behavior is best in this case.
  Florian: No strong feelings, but don't disagree.

  dbaron: I often click somewhere else to unselect things.
  Florian: If you select text and then click the title bar you do
           not unselect
  dbaron: The title bar isn't part of the page, try the margin
  [I see select-none used on body to try and prevent copying of the
  <dbaron> I also couldn't hear the middle of what glazou said
  astearns: Does user-select: none means I'm not going to interact
            with the selection? If so I expect the deselect behavior.
  glazou: Could be a database value that the user can't change;
          don't want to change the selection if you click it by
  Florian: Let's say you are making a mail field with to, cc, etc.,
           but the cc label are UI elements and these tend not to be
           selectable and when you click them they don't change the
  Florian: If you try to mimic this as a web app you'll probably
           want the same behavior.

  smfr: I think Chrome, Safari, etc. are emulating behavior on a
        mac, if you click on an unselectable it doesn't remove the
        selection but drag does, it's for compat with native code.

  <dbaron> I think Florian's comment about them being UI elements
           was reasonably convincing

  Rossen: Has anyone tried reaching out to the editing wg?
  Florian: I could.
  Rossen: It seems we're trying to define editing behavior in CSS
          while the editing group is trying to deal with these
  Florian: I'm hearing we need more input, but we do want interop.
  Florian: I will take this to the editing wg.

  [question about chrome performance not minutes]

  astearns: I heard smfr mention Mac native behavior
  astearns: but that's only native on one platform,
  astearns: Chrome also tries to match native behavior on each
            platform, so if mac and windows differ we may want
            something different.
  Rossen: I think Mac and Windows are here but need to check.

  ACTION: Florian to get back to editing tf and do research on
  <trackbot> Created ACTION-787

Ambiguities in handling url()

  <astearns> https://github.com/w3c/csswg-drafts/issues/383
  <fantasai> I thought we're deferring url() ambiguities to TPAC
  * fantasai is no longer able to speak up, sorry
  <fantasai> yeah, TPAC
  [moved to TPAC]

Algorithm of `Element.offsetParent`

  <astearns> https://github.com/w3c/csswg-drafts/issues/409
  smfr: Any changes here has compat risks but we may be willing to
        change it and see what happens.
  Rossen: In our case I'm pretty sure we do say containing block but
          I haven't looked recently.
  Rossen: So I'm not quite ready about this issue.
  <bkardell> +1 to next week
  [deferred to next week]

Segment Break Transformation Rules for East Asian Width property of A

  <astearns> https://github.com/w3c/csswg-drafts/issues/337
  <fantasai> This probably needs i18n input
  <fantasai> The issue is that punctuation is shared
  <fantasai> and we currently assume EAW ambiguous punctuation is
             narrow (non-CJK)
  <fantasai> when deciding whether to transform newlines to space or
  <fantasai> An earlier draft looked through punctuation to the
             first non-punctuation character
  astearns: I'll ping Richard about getting an [i18n] opinion on
            this one

  <fantasai> And the algorithm was simplified. So now we have a
  <fantasai> One way to deal with the issue would be to just pick a
             behavior here; other way is to look through punctuation
             to non-punctuation character (limiting to 3 chars,
  <fantasai> i18n would need to advise on the first approach; csswg
             on the second.
  <fantasai> So I guess that's a question for the csswg -- which
             approach to take

Value is used value?

  <astearns> https://github.com/w3c/csswg-drafts/issues/336
  Florian: User select is not inherited but auto sort of does
  Florian: Microsoft prefers to keep it at computed value time but
           Blink doesn't. So proposal is to split user-select into
           two values.
  Florian: New is user-select-contain: none | contain and is not
           inherited; other would be user-select: text | all | none
           and inherited

  [question about user-select unprefixed from fremy]
  Florian: Unprefixed is implemented but I think common in the wild.
  Florian: We would have a shorthand and longhand where one was
           inherited and the other not, which is unusual.

  gregwhitworth: Where did all the other values came from? Seems
                 like majority of implementations have text and none.
  gregwhitworth: I feel like we're overcomplicating this.
  gregwhitworth: Why didn't we match what MS already implemented?
  Florian: [mentions ugly historical artifact]
  Florian: It's close to the MS behavior now
  gregwhitworth: Microsoft's position was we didn't want to change
                 any code but that's the way we're starting to lean.
  koji: For blink our storage system doesn't have a mechanism to
        have inherited and non-inherited values in a single property
  koji: so we'd have to store this for all boxes.
  koji: So this will add cost to every single document even if it's
        not used.
  Florian: I think there was a similar answer from gecko.
  gregwhitworth: If the end user scenario is achieved by our

  astearns: Are there other instances with non-inheriting and
            inheriting values?
  Florian: Technically it's not inheritance.
  Florian: The difference between inherit/not doesn't really matter
            without the contain value.
  dbaron: It does matter if you look at the computed value.
  Florian: The OM was never implemented for this property in Gecko I
  <dbaron> pretty sure Gecko implements getComputedStyle for all
           properties that we implement

  Rossen: Ignoring implementation complexity, what makes the most
          sense from user perspective?
  Florian: I'm biased :) but I think the current spec is more
           intuitive, and proposal lets you express the same thing,
           with 2 properties rather than one. Some of the new combos
           are the same some not,
  Florian: which makes me lean to the current spec as being slightly
           more intuitive.
  koji: I believe we could make 2 properties as Florian said.

  Scribe: TabAtkins

  astearns: I like the approach of taking this from an author
            perspective - what's easier for an author?
  astearns: I tend to agree with Florian that a single property
            seems easier.
  astearns: The complexity just for simplifying how we compute
            "auto", if it's not also giving authors something, seems
            unneeded to me.
  koji: Sounds like we can come up with designs with two properties,
        but one shorthand, that make implementation simpler and not
        affect author usability?
  Florian: If we can do that, in practice the implementation
           difficulty you're facing, you can solve it by having the
           current property be the shorthand, and the longhand be an
           internal property, not exposed to the author.
  Florian: That sounds like an action on me to see if the
           shorthand/longhand combo can exist, and if it can, if
           there's a reason to expose the longhands to the author?
           Or is this not where we're headed?
  astearns: Sounds promising to me.
  * fantasai notes that we're adding an inherited/non-inherited
             longhand combo to the 'fill' and 'stroke' properties

  Rossen: I'll find you someone who worked on this on our end, I
          think that's Matt Rakow. Might want to reach out to him,
          he worked extensively on this a few years ago.
  Florian: Ok, do you recall if it was easy on your end or if it was
  Rossen: I recall spending several hours on this, but it was doable.
  astearns: I'd also suggest getting some author feedback.
  astearns: See if we can discern a preference.
  Florian: Probably need to bikeshed it a bit more first; having one
           with settled names and one with draft names isn't a fair

  ACTION Florian to continue with the shorthand/longhand idea for
  <trackbot> Created ACTION-788

  <Bert> Please, remind your AC reps of
  Bert: 1 week left to review the charter
  astearns: Comment period until the 2nd of September.
Received on Thursday, 25 August 2016 01:29:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 August 2016 01:29:04 UTC