[CSSWG] Minutes Telecon 2015-04-15

CSS Houdini F2F
---------------

  - Anyone planning on or interested in attending the CSS Houdini
      F2F in conjunction with the August F2F was asked to please
      contribute to the email thread planning dates, available here:
      http://lists.w3.org/Archives/Public/public-houdini/2015Apr/0018.html

Selectors Profile Bikeshed
--------------------------

  - RESOLVED: Rename 'fast' and 'slow' profiles to 'static' and
              'dynamic'

Selectors 4 Matching Algorithm
------------------------------

  - For now, conversation will continue on the mailing list to allow
      more space to explain the complex algorithm and its
      relationship with the work being done on CSS Scoping.

Copying text-transform'd Text
-----------------------------

  - There was some disagreement as to if all text-transforms should
      be removed from a plain-text copy/paste or if there are some
      worth maintaining.
  - People also disagreed on what behavior would be viewed as a bug
      by users.
  - fantasai will reach out to the editing taskforce to get their
      feedback and use that to inform how the existing spec should
      be written and if there's a need to create a spec to just
      address copy/paste issues

CSS UI 4
--------

  - There was disagreement on the approach to and need for adopting
      user-select
  - The 'auto' and 'none' values for the appearance property were
      agreed upon, but there was a lot of resistance to the 'button'
      value.
      - For now, Florian will move the 'button' value to a note
          describing how the appearance property could later be
          extended if desired.
  - RESOLVED: Accept 'auto' and 'none', do research on the rest.

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

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Sanja Bonic
  Bert Bos
  Bo Campbell
  Adenilson Cavalcanti
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Ian Vollick
  Greg Whitworth

Regrets:
  Dave Cramer
  Daniel Glazman
  Simon Pieters
  Michael Miller
  Anton Prowse
  Mike Sherov
  Lea Verou

  Scribe: dael

CSS Houdini F2F
===============

  plinss: Let's start.
  plinss: Since Zakim isn't keeping track, if everyone could type
          into IRC something, present, or so that we can get
          attendance.
  TabAtkins: I'm not on IRC, but on the phone.

  plinss: Anything to add?
  Rossen: I have one about next CSS Houdini F2F.
  plinss: Let's do that.
  Rossen: So there's a mail thread about organizing the meeting
          before or after the Paris F2F for Houdini. This is
          something we agreed on at the February F2F.
  <gregwhitworth>
http://lists.w3.org/Archives/Public/public-houdini/2015Apr/0018.html
  Rossen: This is an FYI if you can go and do your +1 or don't care.
          If we have critical mass we'll try and get together. Most
          like after the F2F in Paris which is currently Tues-Thurs,
          25-27 Aug. So most likely we'll spill into Fri and Sat.
          That's an FYI.
  Rossen: We'll do details on the mailing list and hopefully Mozilla
          can host us for a day or two.
  <tantek> +0 for after. (0 only because I'm not critical for this)

Selectors Profile Bikeshed
==========================

  TabAtkins: Everyone seems fine with 'dynamic' and 'static' and I'm
             happy with the rename.
  <fantasai> +1
  <astearns> +1 to static/dynamic
  plinss: The proposal is to rename 'fast' and 'slow' to 'static'
          and 'dynamic'. Any problems with that?
  tantek: That sounds like an improvement.

  RESOLVED: Rename 'fast' and 'slow' profiles to 'static' and
            'dynamic'

  plinss: We heard from MS that they're still working on item two.
  Florian: A quick note, I sent a pull request to change what we've
           already agreed to. It would be nice to hear back.
  tantek: Okay, thank you.
  Rossen: Once we have news we'll discuss.

Selectors 4 Matching Algorithm
==============================

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Mar/0432.html
  <fantasai> I don't even understand why we have this algorithm in
             the spec
  dbaron: So, selectors, there's new prose in selectors 4 that tries
          to define a matching algorithm. I wasn't that happy
          because it essentially defines it in left to right
          matching which isn't how selectors are implemented. There
          might be things easy one direction and hard the other in
          both directions, so I think it's better to have the spec
          match the implementation. There's also risk of introducing
          subtle mistakes.
  dbaron: If there's an algorithm, and I think why TabAtkins wrote
          it is to make it clearer how it works...
  TabAtkins: That was the inspiration.
  TabAtkins: It was written to clear up and tighten up prose around
             matching when I was writing CSS Scope. As soon as you
             have tree crossing you have to do something interesting
             with the selector. The reason why left to right is
             that's seems to match better what authors thought. Also
             it makes the tree crossing easier because the left edge
             is what matches. The right edge might be a different
             tree. It seemed to be written left to right,
  TabAtkins: but once we tree cross it gets a lot more complex. I
             can chop it up or I can write it more universally and
             have a check at the end, but those don't match
             implementation. I think implementation-wise, ours finds
             a lower tree and moves it in and then does a tree trick
             at the end. I don't know if that's the right way.
  TabAtkins: I would appreciate guidance about what is reasonable,
             that was just simplest.

  fantasai: I think if you evaluate a selector against a single
            element in a tree because that's kinda the way the rest
            of the spec talks about selectors.
  TabAtkins: That's the problem, though. Which element? You have a
             selector in some high context matching a nested context.
             If you're going left to right you have to match against
             the right side that's in a higher context.
  dbaron: I don't understand what the tree crossing thing is given
          the difference you described.
  TabAtkins: What I'm referring to?
  dbaron: No, the behavior you're trying to define. I don't know how
          productive this will be on the telecon.
  TabAtkins: I responded on the thread, so we can hash out there. I
             said it in an e-mail and there wasn't a response, but
             we can continue there.
  plinss: So back to e-mail

Copying text-transform'd Text
=============================

  fantasai: We have mostly interoperability on not copying the
            transformation. There's some stylistic changes where it
            doesn't make sense to keep if you copy plain text. So I
            was going to clarify that in the spec text.
  fantasai: The ones that don't do this is Safari and Chrome.
  <dbaron> I think most authors will consider that a bug.
  <dbaron> certainly users

  Florian: I generally agree what we should copy/paste is the
           original, but we might want to be careful saying if you
           copy in rich text you may preserve.
  fantasai: Do you preserve as a style by changing the character
            codes, or is it if it happens to be a CSS style you keep
            it.
  Florian: I'm agreeing with plain text, but I think that if the
           rich text you're pasting into can preserve it we should,
           but if it can't you don't. I don't think we can define
           how rich text works, so just say you can do it if you
           can, but if you're pasting plain text don't do it.
  fantasai: I think that the data store, whatever is the original
            format, it should stay in that.

  dbaron: I think users will tend to consider not copying what you
          see as a bug.
  Rossen: I agree.
  fantasai: If authors intend those things to be capital letters or
            whatever it should be in the data store.
  fantasai: If I have something that I want to have as a heading and
            have text-transforms to do fancy things, copying it out
            should give you the same thing as was there originally.
  <fantasai> Copying out a heading with text-transform vs. heading
             with small-caps should give the same result.

  tantek: Has anyone done user testing?
  Florian: I think this also depends on what text-transform you're
           using. There is a text-transform in Japanese that changes
           small kana to big ones. It's only appropriate for text
           typeset as Ruby. If you paste as plain text and preserve
           the transform, the result is simply incorrect.
  plinss: I think we have a few cases where it makes sense to
          preserve the original text on the DOM and a few cases
          where it makes sense to preserve the transformed style.
  Florian: And as fantasai said if they want something to stay, they
           should put it in the DOM
  plinss: So say the text must be available in plain formatting but
          they may preserve for rich text.

  tantek: And this is one case of a broader set of problems. If you
          copy a list do you get the bullets and if you do do you
          get whatever characters are specified.
  <ChrisL> agree that copy/paste is wildly underspecified

  fantasai: This is a formatting thing, not generated content. We
            should be able to get both results. If we make this
            behave as if you change the DOM you can't get both
            behaviors. The second things is it's a decision between
            small caps and all caps, it should be a stylistic choice.
            You should not have to worry if it will copy/paste
  tantek: I don't think authors worry about if it will copy/paste.
  fantasai: I don't think they'll think about it, but it shouldn't
            have an unexpected side effect.
  Florian: I think either could be considered unexpected.
  tantek: It's because we don't have a copy/paste spec.
  Florian: I agree with you, tantek, but fantasai pointed out that
           generated content is different than the DOM and if you
           take her suggestion authors can get the behavior, that
           seems to mean we're getting an answer. I think it is a
           problem not to have the spec, but we should try to solve
           this case if we have a solution.
  tantek: As we solve these individual cases and we're dealing with
          trade-offs here, I think we should use 'should' wording
          rather than 'must'. That's my suggestion for this general
          area.

  hober: Another thing that comes to mind to me is selection, coying
         and editing move together code-wise.
  hober: The people that hack on webkit are the people to talk to
         about this and aren't typically on CSS meetings. Maybe we
         should talk to the editing task force to see if they would
         chime in.
  tantek: That's an excellent idea.
  fantasai: If someone would give me the email I can do that.
  tantek: Would someone be willing to start a copy/paste taskforce?
  plinss: I don't think we need a taskforce, but possibly a spec.
  tantek: No, not a taskforce, a spec.

  plinss: Let's ping the editing task force and maybe we need us a
          spec that defines this based on what we hear back. Does
          anyone have contact info?
  Florian: It should be on the editing spec.
  tantek: Which WG is it part of?
  hober: webapps
  <fantasai> My general position is that copy/paste of plaintext
             shouldn't be affected by any CSS formatting except
             'display' and 'content'.
  ACTION: fantasai to ping the editing taskforce
  <trackbot> Created ACTION-680
  * fantasai still needs contact info to complete that action...
  * plinss fantasai: public-editing-tf@w3.org

  <tantek> aside: e.g. in CSS3-UI text-overflow we say *should*
           http://dev.w3.org/csswg/css-ui-3/#text-overflow
  <tantek> "Selecting the ellipsis should select the ellipsed text."
  <fantasai> tantek, yeah but that's a "what is selected when I
             click here" question, not a "what is the content when I
             paste it out".
  <tantek> fantasai - sure, hence aside.
  <fantasai> tantek, Would you consider the implementation correct
             if it copied out the ellipsis itself?
  <fantasai> tantek, that's the level of questioning here
  <tantek> no, because I believe the "should"

CSS UI 4
========

user-select
-----------

  Florian: This was introduced in the precursor to CSS UI. It was
           dropped and it wasn't spec'ed, but browsers implemented
           it differently and people use it.
  Florian: I put together a draft spec, I'm not trying to invent
           new values, but to spec how browsers work when they
           agree, and to get them to converge on something
           reasonable when they don't.
  Florian: There is a spec, I'd like feedback, this doesn't match
           any particular implementation, but it is based on the
           current implementations.
  Florian: There's nothing particular for the call, but I'm asking
           for review, unless someone has feedback now.
  tantek: When I initially wrote user-select, the goal was to
          capture a bunch of the UI behaviors that native HTML
          provides and to be able to create a basis to create things
          like check box.

  [Gap in minutes due to connectivity issues. Basic gist of what was
    said with some comments when possible:
    - tantek continued giving a historical prospective on
        user-select and said that the group needed to decide between
        taking a very small, limited approach and going for a
        broader property. He believed that the proposal leaned more
        toward the broad approach.
    - Florian responded that what he spec'ed was somewhat broader
      than what is implemented by any browser, but only to the
      extend that it covers the superset of the implemented behaviors.
      It is not as far reaching as the early proposals that also
      handled selection from drop-downs in addition to text selection.
    - Florian said there was some user feedback being worried that
      this could be abused as a copy protection system, so he
      tried to make the spec clear about this not being appropriate.
    - tantek also pointed out that it would be good to put in
        information about items being copy/paste friendly for a11y
        reasons and Florian agreed that some text in regards to that
        should be added, and invited Tantek to provide it.
  * fantasai is of the opinion that this property shouldn't exist in
             CSS, should be some kind of thing at the behavior level
             (HTML/DOM/etc.)
  * fantasai it doesn't seem to be about style
  Florian: This is indeed not really about style, and is more of a
           behavioral property. However it doesn't belong in DOM,
           as it is not tightly coupled to the content. CSS UI
           as a module has been home to various non-stylistic
           properties that belonged to CSS in the sense that they
           use CSS mechanisms (selectors, cascading...), and are
           not tightly coupled to the content.
    - tantek believed that Fantasai's point is a commonly raised
        issue about CSS-UI, but all of CSS UI was meant to
        function in a broader context. He offered to put a note
        in level 3 explaining this.
  * fantasai doesn't think this comment applies to all of CSS3-UI
  * fantasai thinks this comment only applies to ime-mode and user-
             select

  <ChrisL> prefer to see that in css ui 4, to not slow down 3
  Florian: Yes, that's where it is.
  <bradk> User select is about style when you create a purely
          decorative pseudo element that shouldn't be interfering
          with what can be clicked.
  <fantasai> bradk, it doesn't control pointer events, just
             selection
  <bradk> You're right. I was thinking off pointer events

Appearance Property
-------------------

  Florian: This is somewhat similar to user-select, in the sense
           that this is a proposal inspired by implementations,
           which has a much more limited scope that the earlier
           spec version.
  Florian: Rather than try to establish an exhaustive list of
           all the possible values needed to describe all form
           controls, which has proven unmanageable given the wide
           differences between implementations and in practice
           is only ever useful in the UA style sheet for most
           values, I'm relying on an auto value for that, and
           the main use case it to use the none value to turn
           that off and be able to use CSS to style the control.
  Florian: A side use case is that while it's true that not all
           values are useful, some of them are. So, I have for
           now just one value, letting you get the button.
  Florian: We can expand the list, but I think we shouldn't try to
           get everything. We need to limit to what authors want and
           what we can define.

  Rossen: I wanted to ask you, having dealt with appearance lately,
          the main thing we see on the web is speaking to why this
          came about. We have a closed and not perfect controls
          model in all native controls.
  Rossen: The way people could tap into the controls and try to
          restyle a button or something. I don't now if you're
          proposing to tone it down or to take it to the next step
          which is formalize it further. If we're deigning a
          controls model, there's enough from a component model, we
          should try to align with those in the future.
  Florian: Should I reply, or let dbaron go?
  dbaron: Go ahead.
  Florian: My intent is not to try and provide everything that could
           be used to style anything. There are quite a few values
           on the webkit side that correspond to pseudo elements
           where the appearance isn't standard but people might try
           and get the search icon to appear in places where you
           can't search.
  Florian: In general I'm trying to tone down the property. However,
           there are a handful of values for simple controls, but
           are very useful to have. Button is a good example of that.
           I don't think we should try and add complex form control
           control where you want to get the behavior. The
           way I've spec'ed it, you don't change the behavior.
  Florian: Styling something as a button doesn't make it acquire
           the state pseudo classes that only a button has. And as
           soon as you get to complex controls, composed of different
           sub-elements, that is a different story. For that you
           should use web components or something. I'm trying
           to make this exclusively about appearance.
  <fantasai> florian++
  <fantasai> http://dev.w3.org/csswg/css-ui-4/#appearance-switching
  <fantasai> appearance: auto | none | button

  <tantek> I think 'appearance' should be relegated to a UA-only
           property. Not for authors nor users.
  <fantasai> auto UAs may render form controls using native controls
             of the host operating system or with a look and feel
             not otherwise expressible in CSS.
  <fantasai> </q>

  dbaron: I'm not a big fan of auto being a complex list of things
          you expect UAs to implement, especially when those can be
          a list of CSS values.
  Florian: I think they cannot be. The actually long list is very
           different between browsers. There are a few base values,
           but most are not the same and will only be useful in a UA
           style sheet.
  dbaron: I guess I need to look at the conformance requirements for
          auto closely. I'm concerned about doing a lot of work that
          doesn't address use cases.
  Florian: That wasn't the intent. Auto means do the right think
           based on what the host language says for that element.
  hober: You use 'auto' because you need to be able to override
         'none'.
  dbaron: One other point about things like buttons, appearance
          implies state changes in relation to things like hover. If
          you say appearance button you get different styles.
  Florian: I think that's okay. :hover and :active are states that
           exist for any element, so they apply to the auto
           appearance as well. But if you have something like a
           checkbox appearance and apply it to a <div>, the <div>
           doesn't gain the ability to be checked. Active and hover
           are fine, but things don't acquire new states if you
           style them with a different appearance.

  tantek: Given the experience with appearance, the same comment
          about user-select doesn't apply. The effects we were
          trying to do are complex enough that there wasn't a simple
          declarative solution. I don't think this property at this
          point should be recommendation for authors. I know there
          is some legacy that in worth investigating.
  <bradk> Toggling is useful.
  tantek: I don't think we should put 'button'. I don't think we
          should have something there that you can use this for. I
          think they're complex enough where if someone wants to
          turn a <div> or even a link into a button, I don't think a
          single declarative property is the way to do it. We should
          guide people to web components.
  tantek: This is a legacy property. Yes, there's some usage on the
          web, but we shouldn't direct authors there.
  Florian: I think 'auto' vs 'none' isn't a legacy problem. I think
           it's reasonable that your markup would use HTML form
           elements and you don't want them to look like a form. As
           for button and similar values, I'm a bit more on the
           fence. I don't want the whole list like the earlier. I
           think if it's possible to have a sensible model; I think
           it's possible to work out.
  tantek: I used to believe that, but not any more based on
          experience.

  fantasai: I think you're going to have to run some searches for
            web compat because there are values out there. We may
            need to put something in and deprecate it.
  Florian: That's quite possible. Microsoft has implemented
           -webkit-appearance in IE and it supports button.
  plinss: I think tantek's point is valid. Maybe we need to put it
          in and deprecate.
  Florian: We can define and recommend away.
  Rossen: If you define it you encourage use of this. And I'm siding
          with tantek where we should move away from this and give
          ways to better construct web components that would allow
          people to do what they want to do. Talking from
          implementation experience, very recently, I'm not a huge
          fan of the appearance stuff.
  Rossen: We can continue on the ML.
  Florian: As to the web component point, I think it's a much better
           answer to complex controls, but I don't see how it would
           make it look like a native button.
  Rossen: Use a button if you want a button.
  dbaron: What you do with web component is you put a button in the
          component.
  Florian: If what you has has the semantic of the link, why not use
           a link?
  Florian: I strongly think auto and none are necessary. I can see
           the concerns about other values and hear that we might
           want to remove button. If people would read my exact
           language, I'd appreciate it.

  plinss: I don't hear objections to 'auto' and 'none' so let's move
          forward with that. We need research on button.
  Florian: I understand the concern. Please read the spec.
  fantasai: Let's resolve on having 'auto' and 'none' and possibly
            adding a few other values and someone should take an
            action to do web compat research because we might not
            have a choice.

  RESOLVED: Accept 'auto' and 'none', do research on the rest.

  plinss: Who is going to do the research.
  Florian: It would be interesting to hear from Microsoft since
           they've implemented with the webkit prefix.
  Rossen: I think I gave you our feedback.
  Florian: In terms of if it's possible. I heard as to if you think
           it's a good idea, but I'm not sure if I heard if it
           breaks the web to have the button value.
  Rossen: Anything implemented is done so the web works.
  Florian: And you have implemented more values than there is in the
           spec.

  plinss: So who will take an action to do the research.
  Florian: I don't have the resources to do the type of research that
           looks at a large corpus of websites. I have looked at
           blogs and github and stackoverflow, but that's about what
           I can do.
  plinss: Anyone else willing to take the research?
  tantek: Why don't we leave it out pending someone coming forward
          with the research. Then we leave it open for someone to
          say we need it.
  fantasai: Then we should have the implementors say they'll drop it.
  Rossen: I'd be happy with that.
  Florian: I put button in there to make sure that I designed the
           property in a way that made it possible add it if we
           needed it. I would like people to review my spec language.
  plinss: I think the way you did it is reasonable.

  Rossen: Is your expectation with this that we'll implement a
          non-prefixed appearance property? The only reason we added
          it so the web can work. I don't see what you're gaining.
          I'd be surprised if I saw other implementors rush to
          implement.
  dbaron: I think if we're not going to implement the property
          unprefixed we have to implement the webkit prefix. I
          think it's better to do unprefixed with 'none' and
          'auto'.
  dbaron: If we can get people into a not prefixed state, it would
          be better.
  <tantek> dbaron +1 - only un-prefixed just none and auto
  Rossen: I agree with that.
  <fantasai> +1 to dbaron
  <tantek> even one other value 'button' implies a direction we do
           not want to take
  <tantek> even if that means dropping the mechanism for other
           values

  Florian: I want to make 'none' work and have other values we're
           comfortable with... 'none' means we need 'auto'. I have
           'button' to make sure it worked.
  plinss: We have resolution for 'auto' and 'none'. We don't have
          anyone to do research that we need the rest, so I agree
          with tantek to leave them out until someone says we need
          them.
  Florian: I'm okay with taking out button, but I think that people
           should review how I wrote button because I don't want to
           lose it and find we need it.
  <fantasai> Call dropped. My position is that if values are
             necessary for Web compat, then they should be in the
             spec for the unprefixed property
  <fantasai> They can be deprecated, but they should be there.
  <fantasai> I'm unwilling to drop 'button' from the spec at the
             moment
  <fantasai> I would agree to do it if all the browsers came and
             said they would drop support.

  dbaron: Can you take the button text and make it a note as to we
          might need to add other things and here's an example of
          how we'd do it.
  Florian: There's some spec text assuming you have more than 2
           values.
  plinss: In general I like your approach and agree if there's more
          values this is how they should behave and maybe that
          can turn into a this property doesn't effect XYZ and I
          think you're on the right track.
  Florian: I can certainly look into seeing if I can cleanly turn it
           into a note, but I'd rather not drop entirely.
  plinss: Put a big issue in it for now and we have a path to move
          forward.
  <fantasai> +1 to leaving in spec, adding issue
  <tantek> +1 to moving everything 'button' related to an
           informative note section (including mechanism for it) as
           a transition to dropping it
  plinss: What brings us past the end of the hour. Thank you
          everyone and I'll see you next week except I won't be
          here, I'm at a TAG F2F.

  <Florian> Tantek, fantasai: I'll put in a issue now, and look into
            whether I can separate things more cleanly so that we
            can turn the related prose into a note or possibly drop
            it, without causing forward compat problems.
  <Florian> I have clearly heard everyone's feedback that button is
            not warmly welcome, but I would still appreciate
            feedback to the question "If research shows we have to
            have it, would this be a reasonable way to spec how it
            should work?".
  <tantek> Florian - I don't think people want to bother with that
           level of conditional analysis - that's the problem.
  <tantek> would rather just punt on it until someone brings it up
           later
  <Florian> tantek: I don't want to spec a property that cannot be
            sanely extended in a way we may later find necessary. My
            research shows that there is demand and usage of this
            value, and I wanted to make sure we could have it if we
            had to. The only way I know how to do that is by adding
            it and seeing if the spec makes sense. To me, it does.
  <tantek> The other way is to punt on it and worry about extending
           it later.
  <tantek> We do that in CSS all the time
  <tantek> CSS is fundamentally designed to "extend it later"
  <tantek> no need to pre-worry about "sanely extended later"

Received on Wednesday, 15 April 2015 23:04:51 UTC