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

[CSSWG] Minutes Telecon 2015-01-07

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 8 Jan 2015 06:42:37 -0500
Message-ID: <CADhPm3s4ZmQJVgJu3pAnnHH6Q0SU3B+t5MBkLhggfD7-J=xuqg@mail.gmail.com>
To: www-style@w3.org
May F2F

  - RESOLVED: Meet 18, 19, 20 of May in NYC hosted by Bloomberg
  - Everyone received an action to post topics for the meeting in


  - RESOLVED: Publish with the draft as-is, noting that what's there
              for the OM is just some ideas as a starting point for
  - RESOLVED: keep ::grammar-error and ::spelling-error in the draft
  - RESOLVED: Publish FPWD of CSS Pseudo-Elements
  - fantasai will put her proposal for having descendants of
      p::selection inherit style into the spec.


  - Everyone received an action to review the wiki tracking Flexbox
      accessibility concerns created by bcampbell in order to
      discuss it next week. The wiki is available here:


  -  RESOLVED: we intend 'auto' to cover behaviors that can't be
               described by other styles in the UA style sheet, and
               we want to define it more precisely, but we need to
               work out on the list what that definition should be
  - There didn't seem to be much interest in implementing ::value
      and ::choices in the near future from implementors, however
      the group will wait on a formal write-up for ::placeholder
      before deciding on if ::value and ::choices should be moved to


  David Baron
  Rik Cabanier
  Bo Campbell
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Vivien Lacourba
  Philippe Le Hégaret
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Lea Verou
  Ian Vollick
  Steve Zilles

  Tab Atkins
  Adenilson Cavalcanti
  Alex Critchfield
  Chris Lilley
  Michael Miller
  Shinyu Murakami
  Keshav Puttaswamy
  Greg Whitworth

  Scribe: dael

May F2F

  glazou: Let's start.
  glazou: I'm sorry about the agenda today. As I said, the events in
          Paris disrupted the work day. The emotion in tremendous.

  glazou: Back to the message I sent before, there were two things
          to discuss. The date of the May meeting, we need to
          resolve on that. As I said from the outline, the number of
          seats on planes is declining in Europe because it's a
          vacation week.
  glazou: We resolved to have it in NYC between 18-22 May hosted by
          Bloomberg, but we don't have exact days. andrey are you on
          the call?
  glazou: Let's wait on him, but we can say if we have blockers or
          preferences on days. I prefer the first three days of the
  glazou: Other people?
  <astearns> no preference
  dauwhe: First 3 days is fine.
  glazou: People flying from CA?
  dbaron: I'm happy with beginning because it's closer to the AC
  glazou: No objections if we resolve on first three days? Andrey
          said he was booking a room for the whole week
  <SteveZ> +1 for first 3 days
  <Bert> (Not sure I can come: Also WWW2015 the same week...)

  RESOLVED: Meet 18, 19, 20 of May in NYC hosted by Bloomberg

  glazou: The 2nd item...oh Bloomberg just connected.
  glazou: We suggested to have the main meeting 18, 19 20. Is that
  andrey: Yes.
  glazou: Wonderful. Let's consider it closed.

  andrey: I'll have room for 30 people. Is that enough?
  glazou: I think so. It might limit observers.
  glazou: Let's set up the wiki ASAP and we'll see how it goes with
          that number.
  glazou: We'll need hotel recommendations from you.
  andrey: Sure.

  glazou: Second thing is an action on everyone, we need agenda
          items for Sydney for CSS and Houdini. Please go to the
          wiki and add items.
  <fantasai> https://wiki.csswg.org/planning/sydney-2015

  glazou: Now I'm ready for whatever people want to discuss.
  glazou: I think fantasai wanted something and Florian said
          something about CSS3 UI.
  Florian: I have a bunch on that and one on Selectors, I have a lot
           so I don't want to take all the time.


  fantasai: There's a couple of things. One is the OM section, do we
            want FPWD with that in and do we want an issue or note
            about the status of that and we're not sure if it's
            right. I'd like to know what to do with the OM section.
  fantasai: There's one or two more issues.

  <BradK> Link?
  <fantasai> http://dev.w3.org/csswg/css-pseudo/#cssom
  <BradK> Thanks

  glazou: The OM section...the OM of CSS I think we're going to
          discuss during the Houdini meeting. It seems there's a
          concern about the state of what we have now and we want to
          revamp it.
  astearns: There's already an issue in the section.
  glazou: And it's a FPWD anyway, so it's harmless to put it there.
  fantasai: So put in the OM section and make it clear it may be
  fantasai: Usually with a WD we think we're going in a direction,
            but we're not sure at all.

  RESOLVED: Publish with the draft as-is, noting that what's there
            is just some ideas as a starting point for discussion.

  <fantasai> http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
  fantasai: So the ::spelling-error/::grammar-error, did we want it
            in the draft, or not? There was no resolution at TPAC.
  tantek: I think ::selection should be in the draft, absolutely.
          There's been a lot of demand for it.
  fantasai: ::selection will be for sure; it's the main reason we're
            publishing this draft. Do I include ::spelling-error
  <andrey_r> I was asking for these to be included.
  glazou: In the words of the Mozilla editor there have been a lot
          of requests to style spelling different. Grammar I don't
          remember as much, it's a lot harder to do, but I think
          putting it in the WD will make people think about it.
  tantek: I agree.
  tantek: I think I'm in favor, I think it's important in an early
          version of the draft.

  tantek: What about the security concern?
  tantek: It's based on what's in the dictionary.
  fantasai: There's a section on the security issues that I added at
  <fantasai> http://dev.w3.org/csswg/css-pseudo/#highlight-security
  fantasai: [reads from spec]
  Florian: I'm happy to have that in.
  glazou: So any objections against keeping these two
          pseudo-elements in the spec?

  RESOLVED: keep ::grammar-error and ::spelling-error in the draft

  fantasai: The wording in selectors is problematic because it's in
            a note. It also is...the wording is slightly different
            and we should figure that out on www-style. I'm not sure
            the same wording would make sense.
  tantek: It sounds like there's a general concern about user info
          leakage and that might merit it's own section.
  fantasai: They're in two different specs.
  tantek: Up to you, then. Your choice.
  fantasai: I'll note they should align.
  fantasai: Right now I'm using must, for visited it's may.
  dbaron: For visit it was backwards compat issues.
  tantek: I'm happy with must.
  fantasai: And it's more of a security problem.
  glazou: Not just the address book, but words specific to your work.
  fantasai: Or even some confidential information.

  glazou: Anything else on this?
  fantasai: I'd like to publish FPWD.
  glazou: Fine by me.
  tantek: Yes, absolutely.

  RESOLVED: Publish FPWD of CSS Pseudo-Elements

  glazou: Anything else fantasai?
  fantasai: I think that was the only thing. There's another issue
            on pseudo-elements since we're here.
  fantasai: Let me pull the e-mail.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2015Jan/0053.html
  fantasai: If you style p::selection and you have a descendant, the
            text inside the descendant doesn't get styled in 3 of 4
            rendering engines. I wrote the spec assuming it would
            receive the styling because I think that makes the most
            sense. There's a test case link.
  <fantasai> data:text/html;charset=utf-8,<!DOCTYPE html>%0D%0A
             <style>%0D%0Ap%3A%3Aselection { background%3A rgba
  <fantasai> }%0D%0A<%2Fstyle>%0D%0A<p>Test me <em>and me<%2Fem>.<%2Fp>
  fantasai: This would require the browsers to change their
            implementations. I'd say hold off until we figure out
            exact inheritance, but I want to make sure the WG is
            okay to fix it.
  <dbaron> I agree we should fix the behavior.
  <BradK> Me too
  <BradK> But I'm not an implementor

  glazou: The only thing I'm concerned with is I'm not sure if it's
          consistent on web author expectations. I agree the em in
          your e-mail should receive the style of the p in your
          e-mail case.
  glazou: dbaron agrees we should fix. Other browser vendors?
          Google, Apple, Microsoft?
  smfr: For Apple I'd have to ask David Hyatt.
  glazou: Google? Microsoft?
  <zcorpan> there was a reply from rune about what Presto does

  * sgalineau can't imagine how an author would not consider this a
  <tantek> agreed
  * leaverou sgalineau yup, this is definitely super confusing for
             authors if it doesn’t get fixed
  <sgalineau> leaverou: they might just not use the feature as a
  <leaverou> sgalineau: nope, they will, but with complicated
             selectors to involve every descendant (like
             p::selection, p ::selection)
  <sgalineau> leaverou: yes, some will go to great lengths. others
              will just decide it's not worth the pain.
  <leaverou> sgalineau: it’s not that huge of a pain. It's mainly
             the confusion for authors that don't know it that
             should be a concern.
  <sgalineau> leaverou: I'd get frustrated if rearranging my markup
              a little broke my selection styling. but then I'm lazy.
  <leaverou> sgalineau: yup, I didn’t disagree on that. Unless
             someone is aware of the peculiarity, it’s frustrating
             and confusing

  <tantek> would p ::selection help?
  <tantek> is this an examples thing?
  <zcorpan> tantek: you would need to do p::selection,
            p ::selection {} but it could get messy. suggestion is
            to make p::selection {} DWIM

  glazou: Is it okay for everyone if fantasai puts her proposal in
          the spec and we come back to it later?
  glazou: I think her proposal is the one that makes sense.
  glazou: Any objections to that?
  glazou: Let's do that. Let's change the behavior and make it more
          author compliant.

  fantasai: I think that's all I have on pseudo-elements. I'll
            prepare the FPWD if Bert will help?
  Bert: I won't be able to publish next week. Maybe ChrisL is
  fantasai: I'll ask around.
  * plh can help if needed
  glazou: plh can help. Thanks plh.

  <dbaron> fantasai, has the spec for ::selection defined the
           underlying model, or is it more vague still?
  <fantasai> dbaron, it's pretty explicit, but I'm unsure if it's
             well-written or correct


  glazou: I had Florian has CSS3 UI. Anything else?
  bcampbell: I've been doing research on Flexbox still for break.
  <bcampbell> https://wiki.csswg.org/spec/css3-flexbox/accessibility
  bcampbell: I created a wiki for the arguments. fantasai was nice
             enough to talk to me a lot. I've been talking to IBM.
             I'd like to start a discussion on the e-mail and come
             back to it.
  bcampbell: What I wanted to bring up was I was hoping people would
             keep it on their radar so we can get the comments
             gathered for next week.

  glazou: Let's do an action item.
  ACTION everyone to review

  glazou: What else, or shall we move to Florian?
  tantek: Anyone else having problems with the new repository?
  dbaron: Fine for me, too.
  tantek: Okay. I'll follow up.


  Florian: I'll work off of who is here. Is TabAtkins here?

  <Florian> cursor:auto (ISSUE 48)
  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0531.html

  Florian: This is from dbaron. It's specifying rather than the
           universal "do magic" with auto.
  dbaron: The reason auto is needed is that generally browsers want
          a pointer over not-text and an I-beam over text. Since
          those are often in the same element we need a value that
          switches and auto has historically done that interoperably.
  dbaron: The original auto was so ill-defined it seems that
          everything browsers did with a cursor was under auto.
          Rather I think what can be in the UI style sheet should be
          there rather than all magic in the auto value. I'd rather
          auto is just pointer or I-beam.
  glazou: There's a third for auto which is links.
  dbaron: That can be in UA style sheet
  glazou: Okay, fine.
  <dbaron> Gecko only has 'auto' switch between pointer and the text
           cursors and does other things in the UA style sheet.
  <BradK> User-select:none on text should also prevent the automatic
          text cursor

  Florian: It makes sense to me and I'm in favor of this. We have to
           resolve what it means to switch between vertical and
           horizontal. I have some suggestions on this.
  fantasai: For switching between vertical and horizontal, that
            should be automatic unless we want to add a horizontal
            text cursor and vertical text keyword.
  Florian: We have both, but auto is switching between those things.
          dbaron is proposing that we use auto to switch between
          only those two things. So the question is if we should, I
          have a suggestion for how.
  fantasai: That makes sense to me.

  fantasai: What happens if you have a resizable element and you're
            on the border? If we only switch between these cursors,
            does that mean we don't get a resize cursor?
  dbaron: I have to look, but it's possible we should include it.
          The case where we've gotten bug reports is authors look at
          the spec and auto on a form control should mean the form
          control cursor and on a link the link cursor. I think we
          should say what switching is a part of auto.
  dbaron: I'm probably not going to get an answer for resize in less
          then two or three minutes.
  <SimonSapin> +1 for specs being explicit
  <tantek> I agree with specs explicit however I'm not sure we have
           good explicit language to put in yet.

  Florian: Maybe the resizing behavior is somewhat independent if
           you specify a cursor other than auto you may still and
           resize. I'm not sure on this one.
  <dbaron> fantasai, I think we have the last two but not
  <fantasai> "User agents may automatically display a horizontal
             I-beam/cursor (e.g. same as the vertical-text keyword)
             for vertical text, or for that matter, any angle of
             I-beam/cursor for text that is rendered at any
             particular angle. "

  fantasai: My concern is we have the resize. There's other things
            that could happen like a UA has a button that changes
            what you can do to an item and therefore the cursor,
            like if you hold control it's a hand.
  <tantek> agreed with fantasai concerns
  Florian: That should be doable with normal mechanisms overriding.
  fantasai: So the CSS cursor changes if you hold the control key?
  Florian: A UA that could change through the style sheet. Why not?
  <tantek> depends what you're hovering over
  <tantek> or if you're dragging
  dbaron: I think the question is if the UA has that, do they want
          it to not show if the author chooses cursor and I think no
          in which case you're selecting a mechanism outside CSS.
  <tantek> Isn't that the magic of auto?
  fantasai: I'm just not sure if everything a UA wants to do can't
            be done through the style sheet. If it's out of scope it
            might be completely expressible.
  <tantek> yes, that ^^^

  dbaron: If there's other things that need to be here we should list
          them. I don't think auto should be magic.
  smfr: Looking here we may use the hand or the text input as a
  Florian: If the cursor isn't there do you still show the resize?
  smfr: It looks like we don't.
  dbaron: I suspect Gecko has some sort of anonymous content that
          has a cursor style on it for the resize handle.
  tantek: I'm okay with specifying more details on auto, but I don't
          feel like we understand. There's some cases that aren't
  <BradK> *:dragging { cursor: hand; }
  dbaron: That's fine. We should define what it covers, not imply it
          covers everything that's in the UA style sheet. We don't
          need to define on the call.

  Florian: There's another item where if auto can switch between
           vertical and horizontal, there's also the diagonal. Does
           it do that?
  fantasai: Text says UA can display horizontal for any text that's
            rendered at any angle. So the text says you can, so I
            don't know why you wouldn't.
  Florian: Right, it's just that no one does that right now.
  dbaron: I think that's a recent edit to the spec.
  tantek: I think that's been there for a while.
  tantek: It's been there for a while.
  dbaron: Recent in relation to the change in cursor implementation.
  <dbaron> ok, it changed between the 2003 LCWD and the 2004 CR.
           There were definitely drafts that described vertical-text
           and text as both fixed, though (i.e., prior to the 2004
  tantek: I think the point in IRC earlier is that we don't have an
          explicit horizontal.
  tantek: I think it was added because people were doing it. If you
          want to discuss deprecation, that's another discussion.
  Florian: dbaron suggested on the list about having a switch. I
           don't remember exactly what he said, but if we should
           have a switch it should be possibly rounded to 90 degrees.
           That's the baseline, what we're after.

  Florian: Do we have anything we can resolve on?
  Florian: Is there a resolution we want to get out of this?
  fantasai: I'm not convinced we need vertical either, but it's

  Florian: We could have auto means auto-magic everything or we have
           auto may be a lot of things, but we define what they are
           and how they work and how to switch and everything else
           in the UA style sheet.
  tantek: The point of auto is I want to set this back to what it
          was before I said anything. So it needs to be what the
          author expects.
  dbaron: We don't have that for other properties, though we've been
          talking about having it. I don't think we want to solve it
          with this.
  fantasai: We had the 'default' keyword in Cascade to do exactly
            that for all properties, but implementors asked us to
            remove it.
  zcorpan: I agree with dbaron that what can be expressed in the UA
           style sheet shouldn't be a part of the auto keyword.
  tantek: I'm trying to understand the reasoning. I'm from the
          author prospective where I want it like it was before I
          touched it.
  Florian: This is a general wish for CSS, not a specific one.
  tantek: When that's changed we can address this, but we have
  dbaron: Interop is a disaster on this.

  tantek: Is there a magic other value that UAs use if nothing is
          specified for the cursor?
  fantasai: You put something in the UA style sheet and if nothing
            overrides it, that's what takes effect.
  <zcorpan> FYI https://html.spec.whatwg.org/multipage/rendering.html#rendering
            already says the UA style sheet should contain :link,
            :visited { text-decoration: underline; cursor:
            pointer; }

  Florian: Though we've uncovered that the rules are more
           complicated, I'm hearing a sort of agreement toward
           dbaron's side, if others agree with tantek they should
  tantek: I'm saying we should specify, but we don't know what
          they're doing.
  dbaron: I'm saying I know what we do and Simon knows what Webkit
          does and it's not the same thing.
  tantek: So you don't want interop?
  dbaron: We want to decide what interop should be on.
  smfr: To give an example in the webkit code there's interesting
        things happening if your cursor is over a link. You can
        click the link or click and start editing the link. There's
        a setting that applies to that under the author value right
  smfr: And in addition to that it's something that's hard to
        describe in the UA style sheet.

  glazou: We're not going to solve this now.
  Florian: Do we want to figure out the rules, or do we want to
           leave this as magic? We can decide that and if we want
           the rules, we can do that on the list.
  <BradK> a:editing { cursor: text; }
  glazou: What do implementors think?
  zcorpan: I think it's good to try and get closer to
           interoperability and align.
  tantek: I'm for interop assuming we can do that
  tantek: If we spec in this case do this thing, in this case do
          this, else magic. If we can shrink the magic slowly, that
          would be great. I'd like to see those prop

  <gregwhitworth> Can we discuss this at F2F?
  <gregwhitworth> Regarding cursor: Auto

  Florian: Do we intend auto should be everything, or that the UA
           style sheet should be specific where it can and else auto
           and we try and define auto.
  tantek: I don't think I understand that.
  Florian: Do we want the UA style sheet to have a selector that
           says cursor: auto, or do we want detailed things in the
           style sheet except where we have to decide on auto.
  <zcorpan> the latter
  smfr: I'm fine with the latter. webkit only has links for the
        editing behavior I defined.
  <dbaron> I prefer the latter as well.
  <tantek> I'll defer to the latter
  glazou: So the two Simons are in favor of the latter.
  glazou: Objections?
  <BradK> If we do the latter, then what happens if the author does
          the former?
  <zcorpan> BradK - it would make links have a text cursor

  <dbaron> proposed resolution: we intend 'auto' to cover behaviors
           that can't be described by other styles in the UA style
           sheet, and we want to define it more precisely, but we
           need to work out on the list what that definition should
  dbaron: Does that make sense?
  Various: Yes

  RESOLVED: We intend 'auto' to cover behaviors that can't be
            described by other styles in the UA style sheet, and we
            want to define it more precisely, but we need to work
            out on the list what that definition should be

  <Florian> ::value and ::choices (Follow up on ISSUE 65)
  <Florian> http://lists.w3.org/Archives/Public/www-style/2015Jan/0046.html
  Florian: A while back we decided to drop the pseudo-elements that
           were in CSS3 UI. tantek made the edits, but we found two
           values. There was some evidence of intent to implement. I
           agree that ::value makes sense, I'm not a sure about
           ::choices, but given there's no implementations I think
           they should go in pseudo-elements spec.
  Florian: So what do people think, keep, delete, move?
  tantek: I'm particularly interested in implementor feedback. If
          it's not a priority for other implementors, that's a big
          piece of input, but if they will implement this year, we
          need that. Shuffling spec we can decide later from that
  tantek: This is part of the larger do we want to keep making
          controls JavaScript-y or do we want to add smaller stuff
          to CSS that authors use for control.

  Florian: To me ::values makes sense and ::choices doesn't, but I'm
           not an implementor.
  tantek: As an author's prospective?
  Florian: Yes.
  smfr: I don't think webkit has intention to add these soon.

  Florian: When we discussed place-holder pseudo classes, we only
           added one for when it was shown, I think this was a combo
           between value pseudo class and pseudo element did
           everything you need.
  tantek: I think that was a use case for ::value.
  Florian: If we remove ::value, we need ::placeholder.
  dbaron: We agreed to add ::placeholder. It hasn't been edited into
          pseudo-elements spec.
  tantek: I'd like to see a trail for that and see what's going on
          there. Do you remember what meeting dbaron?
  dbaron: No.
  <astearns> Tucson
  tantek: If we think it's sufficient and it's written, I think it's
          a good interim solution.
  Florian: If we have ::value, we don't need ::placeholder, but if
           we have ::placeholder, we might still want ::value.
  Florian: But back to the earlier question, do people want to
           implement? You've got the comments from Mozilla.
  tantek: I think it was a refocus on ::placeholder

  <dbaron> placeholder resolutions in
  <astearns> email link:
  dbaron: I just put a link to the IRC of the resolution. It was
          February 2013.
  tantek: I was there and I don't remember this, but okay.

  <zcorpan> maybe ::value shouldn't select the placeholder
  Florian: What are we lacking to make a decision?
  tantek: We're lacking a write up of those two pseudos.
  <tantek> we need these written up: :placeholder-shown &
  Florian: It's just ::placeholder that isn't.
  tantek: Should we action someone to write that up?
  glazou: We need to wrap up.
  tantek: So I propose we action a pseudo-elements writer to write
          up ::placeholder
  tantek: I think we should get that out there and follow up

  ACTION fantasai write ::placeholder in pseudo spec
  <trackbot> Created ACTION-664

  <BradK> Is XForms still a thing? Is that the only use case for
  * Florian BradK that's been removed already
  <BradK> OK

  fantasai: It doesn't sound like there's an immediate need to have
            ::value and ::choices so we should drop them to
  tantek: I think we have consensus on one, but not another.

  glazou: We're past the hour. Thank you and we'll see you next week.
Received on Thursday, 8 January 2015 11:43:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC