W3C home > Mailing lists > Public > www-style@w3.org > December 2014

[CSSWG] Minutes Telecon 2014-12-03

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 3 Dec 2014 20:27:29 -0500
Message-ID: <CADhPm3vR=hZWgbq8xrCsxR4YhKnFzi0gEzR-3pa7s_tToY62ig@mail.gmail.com>
To: www-style@w3.org
Follow up on applying pseudo-classes to labels
-----------------------------------------------

  - There were a few people that felt that this would add useful
      functionality, but several people weren't convinced that there
      were real-world use cases.
  - Therefore, Florian will come up with use cases attempting to
      create this behavior and anyone else is welcome to also add
      cases.

CSS3-UI Issues
--------------

  - It was felt that implementors that don't implement 'invert'
      shouldn't parse 'invert'.
  - RESOLVED: Update the spec to make it more clear what optional
      means in the current spec (Issue 42)
  - RESOLVED: Authors must not hide outlines on focused elements
      unless they provide an alternate highlight mechanism for
      focused elements (Issue 43)
  - RESOLVED: UAs may support <image> in addition to <uri> and refer
      to image production as part of the text. (Issue 44)
  - RESOLVED: clamp cursor coordinates individually when invalid.
      (Issue 46)
  - RESOLVED: Do not address this issue (#49, ability to show a
      tooltip with full text when a line is ellipsed) in CSS3-UI

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

Present:
  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Mike Miller
  Simon Pieters
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Dirk Schulze
  Alan Stearns
  Steve Zilles

Regrets:
  David Baron
  Bruno de Oliveira Abinader
  Arron Eicholz
  Simon Fraser
  Simon Sapin
  Mike Sherov
  Lea Verou
  Greg Whitworth

Scribe: dael

  plinss: Let's get started. Anything to add to the agenda.
  Florian: I mailed a bunch to CSS3 UI stuff to the list in addition
           to what we had.

Follow up on applying pseudo-classes to labels
-----------------------------------------------

  Florian: We discussed how :hover etc. would apply backwards, but I
           forgot I had mentioned that we might want to do a
           backwards for pseudo-classes. One way would be to put a
           hook to HTML and make it the same as :active. Another
           would be to introduce a new psuedo-class selector. A
           suggestion was :for.
  Florian: So do we want to do this?
  <andreyr> yes

  tantek: What was the use case?
  Florian: I was wondering about it as a parallel. If you have an
           input element associated with a label using :for
  tantek: So this is a new feature?
  Florian: Yes.

  <Rossen> what do current impls do?
  <fantasai> <label for=foo>Label</label> ... <input name=foo
             id=foo type=checkbox>
  <fantasai> Florian is proposing propagating the input's state to
             the <label>

  Florian: The use case is if you have an input element that is
           invalid and you want to display it in red, you also may
           want to highlight the label that goes with it.
  glazou: So you want to reflect all the properties of one element
          onto another one.
  Florian: You want to be able to style the label based on the style
           of the input since you might want to have a similar
           affect on both pieces.

  tantek: Is anyone doing this with JS? I've never seen the effect
          you're talking about.
  Rossen: What do current implementors do?
  tantek: They don't. This is a new feature.
  tantek: I would propose...I want to see one documented example of
          someone trying to do this with JS. I've never seen this
          and unless there's a use case it should be postponed.
  <TabAtkins> I was trying to say that I've done styling of a label
              based on valid/invalid before.
  <TabAtkins> I did it post-submit, with PHP, but doing it
              pre-submit would obviously be good as well.
  Rossen: I'm with tantek on this one. If there's no clear use case,
          why are we discussing it.
  tantek: I don't want a theoretical use case for this.
  zcorpan: I agree with that, for what it's worth.
  plinss: I think a common use case informs it, but it's not done
          with invalid. I've created a form where you want to
          highlight the invalid data. That's used all over the place
          so there are use cases.
  tantek: I've seen highlighting a form field, but I've never seen a
          modification of the label in particular. If you've seen
          that I'd like a URL to where someone is doing it.
  plinss: One would be sheppard.
  <tantek> URL?
  plinss: I've done it.
  plinss: I've seen it in other places too.

  plinss: Anyway.
  Florian: I dropped and rejoined. While I was away, there was some
           back and forth on if useful.
  plinss: TabAtkins and I are saying we've done/seen it, but no one
          else is sounding supportive.
  Florian: So the options are 'this is not important, don't do', 'do
           it like :active', or 'define a new pseudo to do it'.
  tantek: And another where we don't know if it's important and if
          it is, please document a use case on the wiki. Link
          somewhere where we can see it's used.
  <fantasai> It sounds like it'd be useful, no objection to doing
             more research.
  <fantasai> Also need to check Web-compatibility
  Florian: I think I found an example on an e-mail.
  Florian: There's no issue.
  tantek: Where does selectors track them?
  Florian: I'll check.
  <fantasai> tantek, by email, with the [selectors] tag currently

  tantek: So, I think we need a use case.
  Florian: There are definitely some. I can write them down.
  tantek: Yes, write them down.
  Florian: Should we go on to next topic?

CSS3-UI Issues
--------------

  Florian: Starting with issue 42. There is an 'invert' value for
           outline that currently says UAs are allowed to not
           support, but it's ambiguous as to what they should do
           when they don't. I'd like to clarify what not support
           means.
  Florian: Some UAs do support 'invert', so we shouldn't remove, but
           not supporting should mean don't parse. An alternative is
           to parse and compute to currentColor. Things would be
           sane, but we can't use the cascade, I'd say just support
           or don't and don't parse.
  Florian: Currently in the ML, I wrote that Firefox fails to parse
           and uses black as the default, Chrome parses but doesn't
           render, Safari parses to transparent, IE and Presto do it
           correctly.

  Rossen: You're proposing if you don't support, don't support it at
          parse, if you support, support all the way.
  Florian: Yes.
  plinss: That makes sense as a default.
  Florian: The only difference is that the spec says you can conform
           without supporting this.

  krit: The chances that Chrome will removing the parsing part isn't
        very high.
  Florian: Why would they not remove it?
  krit: It means any property definition isn't supported if there's
        a reverse part.
  krit: A reverse keyword wouldn't support parsing anymore.
  plinss: They're parsing, but not supporting. They can parse and
          support correctly or stop parsing.
  Florian: Chrome parses and makes it invisible which is just plain
           bad. Safari is halfway decent, but it's not what the user
           is asking for.

  zcorpan: Do we know what the web compatibility impact is?
  Florian: Yeah.

  tantek: Are we considering Presto for CR exit? Can it could as one
          of two implementations?
  plinss: If it's in public release I don't see why it wouldn't.
  <ChrisL> it was a fair question re Presto but current rules mean
           we allow it
  Florian: It's not making active progress, but its been shipped and
           still being shipped.

  tantek: Okay. It sounds like we have interoperability between IE
          and Presto as spec'ed. That argues for keeping it. It
          sounds like we need to tighten spec language for if you
          don't support.
  Florian: I agree. That's what I'd prefer.
  plinss: I didn't hear anyone say drop.
  tantek: There was some saying that on mailing list.
  <Bert> (Make '@supports (outline: invert) {...}' useful.)

  fantasai: We might need to mark as optional since I remember some
            implementations don't want to.
  Florian: Yes, it is optional. What's not clear is what it means by
           'don't support it'.
  fantasai: Then we need to change the initial value.
  Florian: That's taken care of.
  tantek: This is UA specific.
  Florian: It already says if not 'invert', initial is currentColor.
           I don't know if that's good, but it's what people do
           currently.

  tantek: Is anyone in Blink or Webkit willing to drop or fix their
          implementation?
  Florian: I hope so because what it is now is terrible.
  <TabAtkins> Ours is broke as hell, so yeah, we can fix.
  <tantek> Thank you TabAtkins

  tantek: So initial value is the only question?
  Florian: The spec says that you support it or initial value is
           currentColor and that's what proper implementations do.
           Chrome and Safari use currentColor as the initial value.
  tantek: Then the question is...one possibility is to always change
          to currentColor.
  Florian: We could.
  tantek: We simplify for webdev and implementors so that if it's
          not specific it just works that way. If they want invert
          they can try explicitly.
  plinss: You're breaking our two implementations and one won't be
          fixed.
  tantek: Presto isn't maintained?
  Florian: For spec work, hardly.
  Rossen: TabAtkins said they'll fix. Either drop or fix.

  Florian: Chrome stated they won't implement 'invert'. Someone on
           the mailing list from Apple said they will not invert
           colors. That wasn't about the parsing, but they won't
           actually invert.
  Florian: It plays poorly with composition.
  tantek: Halfway supported isn't useful. There shouldn't be parse
          and don't support. That's why I want the opinion...I know
          TabAtkins said he'd fix, but would this make it easier?
          For Rossen do you have backwards compatibility issues to
          change initial value to currentColor?
  Rossen: Don't know.
  <ChrisL> tab, tantek is asking how will this be "fixed" - remove?
           implement?
  * Bert is reminded of the ugly problem with 'position: fixed' in
         IE a long time ago: it was parsed, but didn't work, and
         thus provided no easy way to provide a fallback.

  Florian: If you do support 'invert', it is better.
  tantek: Are there things where we change initial value from one
          level to another?
  Florian: I don't know.
  plinss: I have a vague recollection yes, but I don't remember when.
  tantek: I don't remember doing it and it feels like it would be
          confusing to webdev.

  plinss: I'm not hearing strong consensus about what to do with
          initial value, but I hear that browsers that don't support
          it shouldn't parse it.
  tantek: Sounds reasonable.
  krit: If you don't support 'invert'...?
  plinss: If you don't support it, then the initial value is
          currentColor. The behavior of not parsing if you don't
          support it is how CSS should work and if that's not
          spec'ed somewhere it should be.
  Florian: The spec says you conform if you don't support.
  <fantasai> http://www.w3.org/TR/CSS/#partial
  <fantasai> It's part of the boilerplate for all specs
  tantek: Optional shouldn't be explained in CSS3 UI. Do we have a
          definition for that somewhere?
  plinss: fantasai pointed out that it's in the boilerplate.

  RESOLVED: Update the spec to make it more clear what optional
            means in the current spec (Issue 42)

  <tantek> CSS3-UI issue 42: define "invert" as optional per
           http://www.w3.org/TR/CSS/#partial
  <ChrisL> in current spec or in all specs?

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0494.html
  Florian: Next topic is here (above).
  Florian: It was suggested that it's bad for authors to completely
           turn off outlines on focused elements. It's either a
           usability or accessibility requirement, depending on how
           you look at it. The suggestion is that outlines can't be
           invisible on focused elements unless they provide
           alternate highlighting.
  tantek: I would be okay with a note
  Florian: I'm okay with a note, but TabAtkins suggested we could
           make it a must level so validators could pick it up. We
           do have must/must not sometimes. It seems appropriate,
           but a note is a start.
  Florian: Other opinions?
  * tantek is trying to listen and read
  plinss: Anyone?

  fantasai: Must seems fine to me. Use the advisement class, not the
            note. It should be a conformance criteria. It's not a
            non-normative statement.
  <ChrisL> advisement means "do not ignore this"
  Florian: We should says something. I think it's reasonable to go
           as far as must.

  tantek: I'm reading the original e-mail and it seems like that's
          something we can site and make it specific for outline.
  Florian: I went beyond just the width in the original e-mail since
           there's a bunch of ways to go invisible. I'd like to say
           whatever way you make it invisible you can't do that
           without an alternative.
  tantek: So authors must not hide outlines on focused elements
          unless they provide an alternate highlight mechanism for
          focused elements,
  plinss: Author or UA?
  tantek: Author.
  <Florian> Author
  Florian: Author.

  tantek: If that proposal is good, are there objections?
  Florian: I have a very similar proposal text. It's almost the same
           sentence.
  <Florian> As the outline on elements in the ‘:focus’ state is
            depended on by keyboard users for interaction with the
            page, authors must not make the outline invisible on
            such elements without making sure an alternative
            highlighting mechanism is provided.
  tantek: And I'd provide examples so then we can put warnings in
          validators.
  plinss: Objections?

  RESOLVED: Authors must not hide outlines on focused elements
            unless they provide an alternate highlight mechanism for
            focused elements (Issue 43)

  <tantek> CSS3-UI issue 43: Add author conformance clause Authors
           must not hide outlines on focused elements unless they
           provide and alt highlight mechanism for focused elements (
           e.g. outline-width:0 or outline-style:none)

  Florian: Next one is, the cursor property takes a list of images,
           but it's just taking <uri>s. The reasonable thing is to
           accept image production, not <uri> so we can get access
           to gradients, etc.
  Florian: Based on the mailing list everyone agrees this is the
           eventual right thing, but it's not agreed on if this
           should be in level 3 or 4. There's currently not enough
           implementations of the generalized version to pass to REC.
           I understand, but I'm worried if we just start with <uri>
           people won't do the broader implementation.
  Florian: The compromise is say <uri> and in the future we're
           expecting to go to <image>.

  fantasai: CSS Values and Units, I believe has image production
            defined as <uri> We can say if you support image values
            level 3 you should support as <image>.
  Florian: There's a bunch of browsers that support <image>, but not
           on cursor. So if you support <image> you must apply here
           won't pass. In that respect I'm sympathetic to the
           argument, but I don't want to stop implementing the
           fuller option. That's why I say stick with <uri> and say
           alternatively you an use <image> if they want.

  tantek: In general it's bad form to predict the future. It should
          be more like UAs may support <image> in addition to <uri>
          We don't need forward predicting, we can just say may.
  <TabAtkins> I'm fine with speccing <url> and adding a note saying
              that it will be upgraded to <image> in UI 4, and
              browsers should feel free to implement fuller <image>
              support.
  ChrisL: The way to indicate the future is put it in level 4. That
          doesn't predict, it's actualized.
  Florian: I haven't made level 4 yet.
  ChrisL: Dump this in 4 and make it in 4 so people know where it's
          going.
  tantek: I think we want to have some kind of suggestion in level 3.
  Florian: I like tantek's proposal.
  krit: I agree with it defined as a may.
  <andreyr> +1 for proposal

  plinss: I'm okay with a may, but I'd like it to refer to normal
          image production. Say it should use image production and
          make the image optional.
  plinss: I would like it to talk about the image production in
          values and units.
  tantek: Normatively refer to image production is part of the
          property.
  plinss: Objections?

  RESOLVED: UAs may support <image> in addition to <uri> and refer
            to image production as part of the text. (Issue 44)

  tantek: Which issue was that?
  Florian: 44
  <tantek> CSS3-UI issue 44: UAs may support <image> in addition to
           <uri> and refer to image production as part of the text. (
           link <image> to normative image production in values and
           units)

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0501.html
  Florian: Next one, again on cursor, you can have a bunch of
           images/uri but you can also use the coordinates, but the
           spec doesn't have any limits on that. However, there
           isn't full interoperability on what to do with invalid
           coordinates. You can either plant at the actual cursor or
           ignore it if it's a negative. It seems like planting at
           the cursor is the better option if the actual value is
           out of bounds.
  tantek: That's reasonable. That seems uncontroversial. Clamping.

  plinss: Different opinions?
  Bert: How do you clamp?
  Bert: Do you calculate the position by angle, or ...?
  Bert: Do you clamp each coordinate individually?
  Florian: Individually was what I had in mind.
  Florian: I hadn't tested on that. I suspect it's individual but I
           don't know.
  <TabAtkins> We can test, but individually is likely what's
              implemented, and it's sufficiently simple to work fine.
  <TabAtkins> This is just handling an error case, anyway.
  plinss: Do you know Microsoft's?
  Florian: I don't.

  plinss: Let's resolve we clamp individually and if you have other
          findings we'll revisit.
  plinss: Objections?

  RESOLVED: clamp cursor coordinates individually when invalid.
            (Issue 46)

  <tantek> CSS3-UI issue 44: clamp x y cursor hotspot values at edge
           of image
  Florian: We don't have dbaron right? Then I'd like to skip 48.

  <Florian> http://lists.w3.org/Archives/Public/www-style/2014Nov/0532.html
  Florian: 49. Some browsers, when you have something that's
           ellipsed and you hover over it, it will have a tooltip,
           but other browsers don't support that. Having the spec
           normatively say if you should have support for that would
           solve it. I don't care which.
  tantek: Any kind of automatic tooltip would get objections from
          authors. They don't want random pop-ups. Webkit does this?
  Florian: If you hover over text with an ellipsis, Blink, I believe
           has it active.
  tantek: Over the whole line?
  Florian: Yes.
  <Florian> http://jsbin.com/quhisipiba/1/watch?output
  Florian: I'll check, but I think so. You can test this (above).
  Florian: In this example we have two lines of text with ellipsis
           and if you hover anywhere you get the toolkit.

  Florian: As far as I know this is often complained about by people
           trying to create the tooltip for other browsers and end
           up with two.
  tantek: That sounds like a request for support.
  Florian: It's unclear if everyone wants that.
  plinss: And how do you detect if the UA is doing that?
  Florian: UA sniffing?

  tantek: We had generation of tooltips in a previous draft. Do we
          have user selectors that attempt to style tooltips?
  Florian: I don't think so. There was a lot of discussion, but it
           didn't conclude on anything.
  tantek: Other thing we can do is...no, never mind.

  plinss: I would like to see a way of creating tooltips with a
          :hover and then they can override
  tantek: I think it was generated content at some point.
  Florian: There was a proposal, but then there was disagreement as
           to if it's just text, or have a region...
  tantek: The obvious thing to do is just text, so that kind of
          discussion is annoying.

  Florian: So should we tackle the whole discussion to solve this,
           or until then should we say which way browsers should
           behave?
  tantek: I don't want to recommend UA behavior, I'd rather give
          authors a hook or control.
  Florian: The hook is difficult.
  plinss: I understand the concern. I'm loathe to tell browsers not
          to put a tooltip or say must without a way to suppress.
  tantek: That's a better description of my thoughts, thanks plinss.

  Florian: So despite non-ideal interoperability, you want to leave
           this?
  tantek: There's lots of not-interoperability.
  Florian: I'm not objecting to not defining, I just want to be
           clear. If we're not addressing this, then we need to be
           clear.
  tantek: One way to have it is in terms of a11y, when you ellipse
          content it's not necessarily viewable or accessible, so we
          can encourage UAs to provide a mechanism to access that
          content. There's one in the spec if you support copy/paste.
          Selecting the ellipsis is the same as selecting everything.
  Florian: Even an encouragement isn't enough. We need a way for
           authors to turn it off.

  Florian: I think I'm fine with undefined for now with somewhere it
           saying we want to deal with this eventually.
  tantek: I'm not sure that helps.
  tantek: Our efforts should go into a fix. If there's a proposal we
          can fix it, but else wise we should leave it. If someone
          has a proposal, please put it on the wiki.
  Florian: We should resolve to not address it in CSS3-UI if we're
           going to do that.

  RESOLVED: Do not address this issue (#49, ability to show a
            tooltip with full text when a line is ellipsed) in
            CSS3-UI

  plinss: Anything else we can do in 2 min?
  Florian: Not from me.
  plinss: That's it for the week. Thanks everyone.
Received on Thursday, 4 December 2014 01:27:57 UTC

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