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

[CSSWG] Minutes Telecon 2015-06-10

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 11 Jun 2015 06:30:28 -0400
Message-ID: <CADhPm3u6uDnhLZa3157EUi1GKKMFx-wF9GVOe7zAktbAGX5E7Q@mail.gmail.com>
To: www-style@w3.org
CSS UI 3 LC Comments

  - RESOLVED: Add the suggestion that the default stylesheet for
              HTML should have "resize: both" for <textarea>
  - RESOLVED: Reject issue 95, keep using 'ellipsed'
  - Remaining issues are editorial and will be addressed by the
      authors. If they encounter any resistance to their changes,
      they will bring them back to the group.
  - RESOLVED: Take CSS UI 3 to CR


  - RESOLVED: Don't offer variants of user-select: none proposed
              that Florian was actioned to investigate
  - RESOLVED: Add Florian's proposed text to user-select: none
              regarding its use in template-based editing
  - RESOLVED: user-select must not apply to ::first-line or

Media Queries - custom media definition

  - RESOLVED: Reject custom-media definition change to add brackets
              (proposal here:


  - There was still no resolution on how to handle sideways-left,
      but the proposed options will go into the ED of Writing Modes
      with an invitation for input on a solution.


  Tab Atkins
  David Baron
  Bo Campbell
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Peter Linss
  Edward O'Connor
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin

  Sanja Bonic
  Adenilson Cavalcanti
  Simon Fraser
  Michael Miller
  Hoyjin Song
  Greg Whitworth
  Steve Zilles

  scribe: dael

  plinss: Let's get started.
  plinss: Anything to add?
  Florian: I think koji posted something
  plinss: I saw that.

CSS UI 3 LC Comments

  Florian: We have one more week in unofficial LC. We've had some
           comments. Some of them were non-controversial and I
           changed them.
  Florian: Here's the ones that need discussion:
  <Florian> https://wiki.csswg.org/spec/css3-ui#current-issues

Issue #94: resize: both as default for <textarea>

  Florian: If we start with the first one, #94, timeless is
           suggesting that the default HTML stylesheet should have
           resize: both as a default. I think all browsers that have
           resize: both do it, so I'm fine, but I don't care that

  Florian: What does the group think?
  Florian: IE doesn't implement resize so they don't have it, but
           the browsers that do impl have it.
  <dbaron> sounds fine to me
  TabAtkins: Yeah, it's demonstrated to exist basically, so you

  Florian: Anyone form Microsoft here?
  Florian: I guess not.

  Florian: This implementation that for this to work means overflow
           is something other than visible, but I think they are.  I
           haven't seen a text-area: overflow. I believe it's
           overflow auto.
  TabAtkins: They're auto.
  Florian: I'm pretty sure there's scroll in IE.
  TabAtkins: It's auto in Chrome.
  Florian: I think it's auto everywhere except overflow y-scroll in
           IE, but no one has it visible.
  Florian: I'm hearing weak agreement.
  tantek: That's not informative so we can change at any point.
  Florian: No one objects so I suggest we put it in.

  RESOLVED: Add the suggestion that the default stylesheet for HTML
            should have "resize: both" for <textarea>

Issue #95 - Ellipsed vs. Ellipsized

  Florian: Next is #95
  Florian: Timeless says the word ellipsed as a word isn't in the
           dictionary, but I have have found it in some dictionaries,
           but ellipsized is only in Android docs. But he still
           things go with it because it doesn't mean what we say.
  TabAtkins: Yeah, I think it means give it an ellipsis.
  Florian: No dictionary has what we want.

  tantek: I would reject these grammar/spelling comments unless it's
          a very strong case. That's our job as editors to get it
  Florian: I agree, but I wanted other opinions.
  TabAtkins: I've dealt with this before, but I've just invented a
             word using standard English rules.
  tantek: I think the wording is fine. I would reject that kind of
  Florian: That's my inclination too.

  RESOLVED: Reject issue 95, keep using 'ellipsed'

Remaining Issues & Publication

  Florian: Issue 96
  Florian: He thinks the at-risk section isn't clear enough. He
           wanted the section about text-overflow explaining it's
           about ellipsis and having direct links to the rest of the
  tantek: The ellipsis part of text-overflow isn't at risk.
  Florian: I think that isn't the right place to remind people what
           it does.
  Florian: He also wanted pointers to the exact parts of the spec
           and we're pointing to the beginning of the section. I
           think it's good enough.

  <fantasai> I think this is editorial, doesn't need WG discussion.
  tantek: I agree with fantasai that this level of editorial
          feedback should just be fixed and not do it on the telecon.
  Florian: I just wanted to have agreement to reject, but if you
           think it's not needed we can move ahead.
  TabAtkins: plinss, do we need WG approval for editorial, or just
  plinss: I'm not sure. We should as ChrisL
  <glazou> or Bert
  tantek: If it's okay with the WG I'd like to focus on normative in
          telecon time.
  plinss: I agree.
  fantasai: The editorial stuff, if the commentator objects to your
            resolution bring it to the WG, otherwise just fix. If
            it's terminology, maybe bring it to the WG because we
            like to have consistent terminology.
  plinss: If the change crosses specs it needs to get out there.

  Florian: I brought it up because I wanted to reject, but I'll do
           it without group time. The other issues are similar.
  tantek: We'll be making other changes before CR anyway. I think we
          can take that as editorial prerogative.
  Florian: Okay. timeless and I had back and forth, but he was
           disagreeing with what I was proposing.
  plinss: Let's move on.

  tantek: On that note, since we are nearing the end of the LC, I'd
          like to try and get group consensus on publishing CR the
          Tuesday after next.
  tantek: That's the 30th.
  fantasai: You can't publish CR. It has to go through a process
            with telecons. Once you compile the DoC and can get a
            resolution from the WG that they agree with the
            resolution of comments, you'll turn it over to the
            chairs and they'll get it published later. You can get
            it in the pipeline, but it'll get publish a bit later.
            CR takes longer.
  fantasai: You can get group consensus to publish CR, but not on a

  tantek: So the hopes of getting CR through pipeline, I'm asking
          for group consensus to publish CR.
  plinss: I'm okay, but we need a DoC.
  Florian: We have it in the wiki but it needs to be cleaned.
  tantek: We don't have the formal red/green format.
  TabAtkins: bikeshed makes that easy for you with the issues list

  Florian: There's one point we might want to discuss on the telecon.
           One of the editorial comments from timeless was a11y.
           There was an author note that said they must not remove
           outlines on focus level. He wants us to have a lot
           stronger of a threat in that. It's editorial, but people
           get more touchy about a11y.
  fantasai: You might also link to the guidelines and make it
            brightly colored.
  tantek: On that note, we should make a policy that CSS specs do
          not make laws or something :)

  Florian: Anyway, move on?
  tantek: We want consensus on CR.
  plinss: Objections to taking UI to CR?
  <glazou> +1
  <tantek> +1
  <Florian> +1
  <dauwhe> +1


  tantek: Thanks everyone.


behavior of user-select:none child of a user-select:<not-none> parent

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0002.html
  Florian: I had an action to try and make some variations around
           user-select: none so that if you select the parent you
           either would or would not include the none.
  Florian: I've been through the bugzilla of Firefox and Webkit and
           I don't think we should do this. Firefox has it so that
           if you have a child the user-select: none isn't included
           and there is no bug asking for it to be the other way,
           but webkit has bugs asking for the Firefox way. There's
           no evidence people want the webkit way so I don't think
           we should provide it. If your browser can't do multi-part
           you don't, but if you can you do.
  <glazou> fine by me
  plinss: Objections?

  RESOLVED: Don't offer variants of user-select: none proposed here
            that Florian was actioned to investigate

  <dbaron> I think it sounds fine as long as that's not what
           -moz-user-select: -moz-none is... but I think I discussed
           that with Florian at some point.
  Florian: It's not.

Add a note to user-select:none about use in template-based editing

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015May/0306.html
  Florian: Next is something else I had an action on.
  Florian: It was to put a note saying user-select: none is useful
           in templates in an editor setting because you have an
           overall editable area with a specific area that's not
           editable or deletable like a disclaimer. The way content:
           editable typically works is if you have a non-editable
           thing you can still delete it. But by having user-select:
           none you can't delete. But I really don't think I can say
           that in here.
  Florian: It looks a bit out of scope. If you still want a note I
           have proposed wording, but I'm not convinced we should
           have it.
  Florian: [reads his proposal from the e-mail (pasted below)]
  <Florian> Note: user-select:none on a non-editable descendant of
            an editable element means that in addition to not being
            editable, that descendant is also not deletable, neither
            directly nor by attempting to include it in a broader
            selection and then deleting that selection. This matter
            for example in template-based editing, where an editable
            template may contain sections which must be preserved.

  Florian: It can be a note, but I'm wondering if it's out of scope.
  TabAtkins: It sounds fine to me, but I don't have an opinion of
             out of scope. If we keep it it's fine.
  glazou: I was re-reading it and I'd like to keep it.
  glazou: If nobody objects of course. It's non-normative anyway.
  Florian: What makes me nervous is it's useful if targeted at
           people writing the spec, but if they do something else it
           could set up the wrong expectation.
  glazou: But the people dealing with those in a template
          environment will read both specs. I prefer having the note
          in one place instead of nowhere.
  Florian: Okay.
  glazou: If there are objections I'm happy to withdraw, but I think
          it's fine to leave it if no one objects.
  plinss: Objections?
  <BradK> No objection

  RESOLVED: Add Florian proposed text to user-select: none regarding
            its use in template-based editing

interaction of user-select and ::first-line/::first-letter

  Florian: Next up is this
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0012.html
  Florian: user-select isn't actually inherited, it's pseudo-
           inherited and goes through the auto keyword. If the
           browser wants to support it and ::first-line we have to
           make sure how it works. But I think using it on
           ::first-line or ::first-letter is wrong. If you're trying
           to use this correctly it's through a UI element.
  Florian: I'd like to explicitly say it doesn't apply there.
  tantek: I think not-applying is the default.
  Florian: They have a list that says UAs may apply other stuff.
  tantek: You want it to be must not apply.
  <glazou> +1
  Florian: Yes
  tantek: Okay.
  TabAtkins: Agreed.
  fantasai: Yes.

  tantek: I would add ::before/::after
  fantasai: I don't think it's the same problem.
  tantek: I'd like to force someone to have a use case for it.
  tantek: No use case, no feature.
  dbaron: I think it's extra work to make them not apply.
  tantek: I think it's a compat problem to let them apply by
  fantasai: I don't think anyone is setting user-select on
  dbaron: There's the problem that selection doesn't work with
          ::before/::after anyway.
  plinss: I'm a bit uncomfortable to ::before/::after because it's
          different use.
  Florian: I'm not sure it's so different. These things aren't
           actual content. They could be coming form selection
           because they're not part of the content, but I don't care
           that strongly.
  plinss: I've heard people argue they can't select them.
  TabAtkins: They're not selectable because implementor limitations
             at the moment. If they're selectable in Chrome they'd
             be selectable everywhere in Chrome like normal text.
  Florian: I think we have consensus on ::first-line/::first-letter
           but not the others.

  RESOLVED: user-select must not apply to ::first-line or

  Florian: That's it for user-select

Media Queries - custom media definition

  Florian: We received 2 e-mails from the same person asking for the
           same thing on custom media features.
  Florian: He thinks it's ambiguous if it's a media type or media
           feature and adding parentheses makes it obvious. I don't
           really care, but I see where he's coming from. We should
           answer, though.
  TabAtkins: I'm inclined to say no. Any other customer definitions
             in CSS syntax like alias style won't have wrapping
             syntax. I think it would be weird to break just for
  Florian: I'm okay with rejecting, I wanted to make sure we agreed
           to reject.
  plinss: Other opinions?

  RESOLVED: Reject custom-media definition change to add brackets
            (proposal here:


  koji: There are issue with the implementation functioning
        interoperably. The idea is to have it move to a property,
  fantasai: I don't think this is a good idea because...we don't
            have a problem so long as we have sideways-right and not
            sideways or we change the meaning of sideways to mean
            sideways-right and have an auto value. There are reasons
            to have sideways-left as an inline thing eventually so
            it doesn't make sense long term.
  koji: What are the reasons?
  fantasai: There are uncommon use cases for which is should be
  koji: Is the rtl inside cjk?
  fantasai: That and...

  Florian: Why can you do that on the block level? The rtl inside
           cjk? Doesn't that need to be inline?
  koji: You can do inline block that does it clearly.
  Florian: Inline block brings other things as well.

  fantasai: I don't think this is solving a significant problem. If
            there's a major problem with having it then we can have
            sideways only meaning sideways right and have sideways:
            auto do what sideways is doing. I don't want to change
            the writing mode in such a way...I don't like mixing it
  koji: It's really complicated and we don't want to introduce
        complexity. If you don't like adding the value we can add
        the new property.

  Florian: I'm a bit confused. I thought we agreed at the F2F that
           we could keep it the way we had. What's new?
  koji: How did we agree?
  Florian: We brought up that sideways-right was correctly
           implemented by most people but sideways and sideways-left
           were not and we might want to rename or get rid of some
           of them. After the session we agreed it was fine the way
           it was.
  koji: What we discussed is that the value of sideways depends on
        the value of sideways left. The new question is about
        applying sideways inline or at block level, because
        doing sideways-left inline is hard.
  Florian: Okay. I understand now.

  fantasai: I don't think it's intractable, but might be more
            difficult, so maybe this gets deferred to next level.
  koji: I don't want to leave implementing this in the next level.
  Florian: Is sideways-right an issue, or just left?
  koji: Right is very clearly defined. Sideways-left requires
        additional resources for the baseline and it's really
  Florian: I'm tempted to say it's at-risk and that's fine, but I'm
           not an implementor.

  plinss: I'm not hearing consensus.
  plinss: Are we rejecting? Think about it?
  koji: Rejecting means we have to address other issues and
  fantasai: I don't think we have any open issues. We just need to
            clarify the spec.

  koji: dbaron doesn't want to change, why isn't that an issue?
  Florian: I think koji is brining up an issue that you raised that
           sideways-left is an issue if it can be applied inline.
           And fantasai and I were saying it's more complicated, but
           also useful and it's at-risk anyway.
  dbaron: It feels like there are use cases. It is harder and we're
          not doing it now. My issue is that there is a bunch of
          other wording in the spec that needs to be adjusted.
  fantasai: And that's something I need to fix, but we don't have to
            change the values and feature set, it's clarifying the
  koji: How will they understand how floats works?
  fantasai: It's not going to be too hard, but I need to sit down
            and spend like a month fixing the wording because there
            are a lot of areas that aren't precise enough.
  koji: Is there anything other than rtl appearing in cjk vertical
        flow? If this is really complicated, I don't think that's
        worth the complexity.

  Florian: Could we try and identify what it is that need fixing and
           look at the list and see if it's too small a use case?
  fantasai: The one thing here is the float rules are one or two
            paragraphs. There are other aspects of the spec that
            need cleaning, I don't think this is intractable, but it
            does need to be done. As far as, like, there are a
            couple of use cases where we could make it s block level
            thing and if you want those handled you have to use
            inline block,
  fantasai: but also it makes the model for the user more
            complicated because for things that are similar there is
            more than one switch.
  fantasai: Right now the effect is localized to inside the line box.
            If we make it block-level when we switch we can say you
            ignore text orientation or try and integrate it into
            writing mode, but that conflates the two switches that
            are currently only doing separate things. I'd prefer not
            to do that because it makes it less clear cut.
  fantasai: If we decide it's too complicated, I'd rather set up
            rule on how you ignore values on inline elements.

  koji: What we're trying to do for right also requires writing
        modes. It sounds inconsistent so I prefer the other way.
  fantasai: I don't think authors think in terms of switching
            baselines. They think of how their glyph is orientated.
  koji: It depends on the people.
  <fantasai> I don't think people associate upright typesetting with
             a sideways baseline orientation

  Florian: If I understand, sideways-left at the inline level is a
           problem and -right is not. The natural way to use
           sideways-right within a vertical text is in the inline
  Florian: instead of relying on mixed orientation. If I understand
           correctly I think this should stay an inline level switch.
           I think I'd rather not have sideways-left instead of not
           having this be an inline level switch.

  plinss: I'm not hearing consensus. I'm thinking you go off and do
          some spec work to sort things out. Anyone have anything
          else to say?
  plinss: The next topic is spec publication and we need ChrisL and
          Bert, so we have to defer.
  plinss: Anything else?

  koji: I'm not very comfortable with why we're editing the spec.
  plinss: We don't have consensus on if we'll change so we should go
  tantek: Should we capture the options in the spec?
  fantasai: The spec is in CR and the options have been there for a
            while. People are discovering it's complex as they try
            and implement.
  <glazou> in CR, adding such prose will not be editorial and will
           trigger a re-eval of CR...
  tantek: I'm a fan of capturing the issues.
  tantek: If we're not making quick progress it's good to mark it in
          the spec.
  fantasai: The feature is marked as at-risk.
  tantek: I mean the issues we've come up with that we're not
  tantek: Someone outside the group may have insights.
  fantasai: One issue is that we need clarification. I will do that.
            Koji wants to move one thing to another property to make
            it easier to implement.
  tantek: For that we should put a note on it that we don't have
          consensus and we welcome input.
  plinss: I would agree, but we're in CR.

  Florian: We can put it in the ED which exists even if we're in CR.
  plinss: Is that sufficient or do we republish with that?
  tantek: Would it being put in the ED be a good step for you koji?
  koji: Okay. I think there have been years without progress.
  tantek: That's why I want it in the draft.
  Florian: I think I disagree with the proposal, but I support it
           being recorded as an issue in the spec.
  tantek: I jsut want to move the discussion forward.
  plinss: Let's list the issue in the ED
  tantek: I'm okay iterating on the CR with that.
  plinss: It sounds like we have to publish the CR once there's
          edits on it.
  fantasai: The CR will have to go through a few iterations.

  * dbaron doesn't see how Koji's proposal makes anything any
  <fantasai> dbaron, I think the argument is that it wouldn't have
             the varying BFC issue you raised?

  plinss: That's the top of the hour. Thanks everyone.
Received on Thursday, 11 June 2015 10:30:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:14 UTC