W3C home > Mailing lists > Public > www-style@w3.org > February 2013

[CSSWG] Minutes Tucson F2F 2013-02-04 Monday Afternoon II: Backgrounds and Borders, Placeholder Styling

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Feb 2013 17:05:37 -0800
Message-ID: <511D89E1.7060501@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

Backgrounds and Borders
-----------------------

   - Need more tests
   - RESOLVED: Drop 'space' from 'border-image-repeat' since not implemented
   - RESOLVED: move box-decoration-break from css3-background to fragmentation

Placeholder Styling
-------------------

   Discussed use cases and rationale for ::placeholder pseudo-element vs. :placeholder
   pseudo-class. Need for pseudo-element seems to be largely driven by the need
   to style the text color with 'opacity' so as to make it "fade" regardless of
   the input's color scheme. Pseudo-class allows styling the entire input element
   in response to the placeholder's visibility.

   Discussion points included:
     - pseudo-class vs. pseudo-element vs. both vs. reusing ::value pseudo-element
     - reusing SVG's 'fill-opacity' to address fading

====== Full minutes below ======

Backgrounds and Borders
-----------------------

   Peter: Where are we, and what do we need to do to move forward?
   dbaron: Also need more tests?

   fantasai: A handful of open issues.
   fantasai: One is on clarifying how spread works
   fantasai: I think mostly wording, but might be functionality once we
             figure out what's going on.

   <fantasai> http://dev.w3.org/csswg/css3-background/#changes-2012
   fantasai: There are changes since last CR that we resolved on.
   fantasai: So we'll need to republish LC once last set of clarifications
             goes in
   fantasai: I think that's maybe a day's work.
   fantasai: I think we're waiting for edits.
   fantasai: And yeah, we need more tests.

   Peter: Will Mozilla tests give us good enough coverage.
   dbaron: Probably not
   fantasai: Should get test coverage report for June and see where things
             are missing.
   fantasai: And get CR published for the June F2F.
   fantasai: ... a good target.
   fantasai: I think mainly a clarification about the spread radius.
             smfr, Bert and I will talk at one of the breaks.

   Bert: So there will be some tests coming in the
   Peter: ... the next month
   Bert: ... but those still won't give complete coverage.
   fantasai: That will probably get us to halfway on the test suite.

   Peter: Do other vendors (IE, WebKit) have tests?
   Rossen: [inaudible]
   smfr: probably have some; don't know what state they're in.  Some active
         implementation work on newer properties... maybe can get tests out
         of that.
   fantasai: Can you get the tests in reftest format?

   Bert: Apart from Opera, any implementations of
         background-repeat: spread | stretch ?
   fantasai: there's a 'space' value, not 'stretch'.

   fantasai: If we want to be consistent with flexbox, it should be space-between
   fantasai: Since flexbox led to 3 concepts of spacing (no space on ends,
             half-space on ends, full space on ends)
   fantasai: so we had to come up with keywords to distinguish; ideally
             B&B would be consistent with that
   Rossen: I don't think IE implements background-image: space
   dbaron: I think Gecko implements border-image-repeat: space

   fantasai: the option we should have put in spec for border-image is the
             one we didn't include in flexbox
   fantasai (responding to dbaron): border-image-repeat: space is no space
             at ends, but should be full space at ends
   Peter: do we want to change this?
   fantasai: on the plus side, we don't need to rename anything, we can
             just add new values
   Peter: If we're in CR, should we just drop and move to level 4?
   dbaron: I'd be in favor of dropping
   fantasai: I'd be in favor of dropping; then we can add all 3 spacing
             variants in level 4.

   Peter: anything else to shift?
   fantasai: Put box-decoration-break in fragmentation?

   dbaron: Level 4 could just be level 3 plus all the things we just took
           out of it.
   fantasai: I don't think level 4 is that far away.
   Peter: objections to removing?
   dbaron: background-repeat or border-image-repeat?
   dbaron: I think border-image-repeat: space probably interoperable
   fantasai: I think if it's in border it should stay in background
   dbaron: I don't see why.
   smfr: I don't think WebKit has space for border-image-repeat
   dbaron: Sorry, I was getting space and round mixed up
   dbaron: So I'm ok with dropping space from both.
   dbaron: We do stretch, repeat, and round for border-image-repeat.
   RESOLVED: drop 'space' from background-repeat and border-image-repeat
             in level 3 of backgrounds and borders

   fantasai: The next question is do we want to shift box-decoration-break
             to fragmentation?
   Bert: already marked at-risk
   RESOLVED: move box-decoration-break from css3-background to fragmentation

Topic: figuring out next topic
Peter: viewport units?
resolved last week
Peter: overflow?
dbaron: not ready
Peter: placeholder styling?

Placeholder Styling
-------------------
Scribe: fantasai

   fantasai: Seemed from the last discussion that pseudo-class was better
             option except for the one problem that you can't style the
             text with opacity
   fantasai: So makes sense to me to define the pseudo-class, and address
             opacity generally
   dbaron: I think it would be useful generally to be able to style the
           contents of an input
   Tantek: That's ::value from the old UI spec. Let's just use that.
   dbaron: It's not clear from the spec that ::value applies to input elements
   smfr: So pseudo-class applies to input element when it is showing placeholder
         text?
   smfr: So as soon as you click into it, and the placeholder text disappears,
         it no longer matches?
   Tab: If that's how the UI works, then yes
   plinss: Sounds like we're not going to do a pseudo-element, use pseudo-class
           and fix ::value?

   http://wiki.csswg.org/ideas/placeholder-styling
   Tab: sylvain added #6, which doesn't track the HTML name
   fantasai: I don't see a need to mismatch the name...
   <tantek> see also: https://bugzilla.mozilla.org/show_bug.cgi?id=457801
   <tantek> see also: https://developer.mozilla.org/en-US/docs/CSS/:-moz-placeholder

   TabAtkins: So question is what to do for the full solution
   fantasai: 3 + 5 seem useful to me
   fantasai: If there's other reasons to style the value, other than opacity,
             then we should have ::value
   fantasai: There's definitely other reasons to manage text opacity independently

   TabAtkins: Why did dbaron want ::value
   dbaron: Specifying backgrounds and borders turns off native theming in many
           cases, but it might be useful to specify backgrounds without turning
           off appearance
   dbaron: Would also rather solve this problem without a big project like #5
           (applying fill-opacity to all text)
   <dbaron> Tab: fill is complicated because of images; stroke is complicated
            in general
   fantasai: #5, just doing fill-opacity, doesn't seem more complicated (in
             fact seems less complicated) than adding a pseudo-element.
   fantasai: just multiply text color by that opacity
   dbaron: Concerned about Web compatibility
   ...

   smfr: Placeholder pseudo-class seems to blur styling the placeholder text
         with styling the value of the property
   smfr: Suppose you style the placeholder with a larger font size. Does
         the input shrink when you click to type into the input?
   tantek: An analogy to look at is styling ::first-line
   * fantasai doesn't get that
   smfr: I prefer to think of placeholder content as a pseudo-element.
         It sort of hovers over the top. I think that's how we implement it,
         too.
   smfr: So solution that uses pseudo-class to add fill-opacity doesn't seem
         quite right to me.
   plinss: Are there arguments in favor of pseudo-class over just
           pseudo-element?
   TabAtkins: pseudo-class is strictly more powerful
   TabAtkins: Can do other styling based on whether placeholder text is
              present, styling of the input not just its placeholder text
   <florian> From the bits I get via IRC, it seems to me that the combination
             of a pseudo class and ::value is good. generic and powerful.

   SimonSapin: Can't use :empty because input is always empty in the DOM.
   <dbaron> my old pseudo-attributes proposal:
            http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html

   smfr: I'm imagining a UA that wants to show placeholder even while you
         are typing
   fantasai: Might want to show it as a tooltip, even while you are typing
             a value
   fantasai: Seems to me that the pseudo-element better reflects the structure
             of what's going on
   fantasai: [summarizing smfr] the UA may want to display placeholder text
             in some way (off to the side, tooltip, etc.) simultaneous with
             a partially user entered input text value
   fantasai: In this case, you really don't want to be styling the input,
             you want to style specifically the placeholder text.
   SimonSapin: So, do we want to have separate pseudo-elements for the value
               and for the placeholder?
   ...
   dbaron: You wouldn't want the same style for a placeholder text displayed
           inline in the input vs. as a tooltip
   tantek: Are there cases where the placeholder is shown together with the
           value?
   fantasai: I think I might have seen cases where it's treated almost as
             a background image, you type over it as you type
   fantasai: I can see that it would be very useful for things like dates,
             IP addresses, phone numbers, other formatted text where leaving
             the placeholder visible until you type that character
             shows you exactly what you need to type next.

   <SimonSapin> HTML spec: "The placeholder attribute represents a short
                hint (a word or short phrase) intended to aid the user
                with data entry when the control has no value."
   <SimonSapin> 
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute
   <fantasai> SimonSapin, you could use it as a tooltip easily, and that
              would be reasonable per HTML spec. I also agree with dbaron
              that we shouldn't apply ::placeholder styling to it if it's
              rendered as a tooltip rather than a placeholder, though.
   SimonSapin: "when the control has no value"

   <florian> pseudo-class + ::value or pseudo-element alone both make sense
             to me. Pseudo-class + fill-opacity feels a bit contrived.
             It would work, but doesn't sound like attacking the problem
             with orthogonal concepts that are likely to play well with
             future ideas.
   Tantek: I think that's why ::value would make sense
   Tantek: But I also see author wanting to clearly target one (::value)
           or the other (::placeholder)
   smfr agrees with this logic
   Tantek: we could have both a pseudo-element and a pseudo-class for
           placeholders
   dbaron: I'm fine with that, though might want to change pseudo-class
           to something more complicated, like e.g. :has-placeholder
   * smfr suggests :placeholding
Scribe: dbaron
    Discussion leads to :placeholder and ::placeholder-text.
    dbaron suggests that maybe it should be ::placeholder with the pseudo-class
            having another name

   fantasai: could we call it :blank?
   fantasai: Should we have :blank in general for form controls
   Tantek: object to :blank, too close to :empty
   fantasai, Tab: :empty is useless
   <dbaron> my old pseudo-attributes proposal (again :-):
            http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
   dbaron: UA's exact conditions for when it shows a placeholder may vary
           a bit
   fantasai: why would you want to style the input as a function of when
             there's a placholder?
   Tantek: maybe styling a background?
   smfr: maybe UA wants to show placeholder only before the user has
         interacted with a field
   Tantek: we talked about "dirtied"
   dbaron: Along these lines, :valid and :invalid turned out useless,
           we needed our own variants
   Tab: now in the spec, :user-error
   Tab: so probably good to tie definition to actual UA semantics; otherwise
        things will turn useless again
   fantasai notes that :valid / :invalid is still useful for querySelector.
   Tantek: resist the temptation to abstract things into a different concept
   smfr: also an area where UAs might want to innovate

   fantasai: :placeholding and ::placeholder?
   smfr: I like ::placeholder, maybe :showing-placeholder?
   Bert: Can't we use ::value?
   Bert: never shown at the same time
   Tantek: easier for authors to understand styling just the placeholder
           text rather than jumping through :placeholder::value abstraction
   Tantek: less powerful but easier to use
   <florian> I like :showing-placeholder::value

   Bert: how would I go about suppressing the placeholder as a user?
   various: ::placeholder { opacity: 0 }
   * Bert pondering input[placeholder]::placeholder {display: tooltip}

   Peter, Tab: should support 'content' in addition to the ::first-line
               properties to support content: attr(placeholder)
   Tantek: I think we have rough consensus on ::placeholder and an unnamed
           pseudo-class

   dbaron: To some degree I'm still with Bert, not convinced we shouldn't
           use ::value
   plinss: If your placeholder is opacity 50%, and it goes to 0, you want
           it to transition over 1s, so that they could be displayed at
           the same time over a transitional period
   <florian> Do we plan to add ::value later and for other reasons? Because
             if yes, I wonder what the difference would be between
             ::placeholder and :placeholding::value. would they conflict?
             Do different things?

   tantek: Liked :has-placeholder
   dbaron: That's ambiguous, might mean "would show a placeholder if empty"
   plinss: That's :can-haz-placeholder
   RESOLVED: Add ::placeholder pseudo-element
   RESOLVED: Add a :is-showing-a-placeholder pseudo-class with a better name?
   <sylvaing> browsers who also have a ::value pseudo are screwed

   szilles: When you use the a pseudo-class are the properties that would
            be used when the placeholder is shown
   <tantek> http://wiki.csswg.org/spec/css4-ui#more-selectors
   <tantek> ":placeholder pseudo-class for when an input element is in
             the state of showing its placeholder text"
   <sylvaing> I don't understand the use-case for a pseudo-element
   * fantasai is still not convinced the pseudo-element is necessary given
              the pseudo-class
   <florian> I agree with sylvain, and would like an explanation on how
             that interacts with ::value for browsers that have it.
   <tantek> sylvaing - opacity
   <sylvaing> tantek, opacity is not an argument at all. we've been over this
   <sylvaing> you don't add pseudo-elements to work around a property
   <fantasai> florian, ::value styles the actual value. ::value does not
              apply to the placeholder text.
   <florian> fantasai, so what does :placeholding::value style? nothing?
   <fantasai> right
   <tantek> So it makes more sense to put the longer name on the pseudo-element

   Tantek: I think we should give the good name to the pseudo-class.
   Tantek: So :placeholder and ::placeholder-value
   * fantasai disagrees
   <tantek> and reserve the more generic name for the state of showing the
            placeholder
   <tantek> :placeholder

   <sylvaing> We can't have ::value and ::placeholder. they are the same
              thing in a different state.
   <fantasai> sylvaing, we're arguing that they're not
   <tantek> sylvaing - you missed the reason plinss gave above
   <tantek> you may want to transition them separately
   <fantasai> sylvaing, that in some cases it could make sense to show both
              simultaneously
   * stearns notes there's a placeholder attribute in HTML, which makes me
             think ::placeholder is better than ::value for this case
   <sylvaing> that is a use-case; but it implies other things e.g. these
              things always have the same size/position by default
   <sylvaing> you don't want authors to have to position/size two things
              every time they want a nice fade

   fantasai: So the reason I don't think the pseudo-class should be placeholder,
             and that the pseudo-element should be placeholder, is that the
             placeholder is a bunch of text; the input element is showing a
             placeholder but it is not a placeholder.
   Tab: I think that's overthinking the issue.
   Tantek: I think if you want to look at the name options in context.
   Tantek: I think :placeholder and ::placeholder-value is the least bad
           naming option.
   SteveZ: I think we need a set of name candidates, but shouldn't bikeshed here.
   Tantek: I think we just need to pick a set of names.
   Tab: I'd like to pick names today.
   <florian> I am with fantasai, placeholder to me can only be the name of
             the pseudo element
   fantasai: I don't want people to be confused into thinking that they're
             styling the placeholder when styling the input element.
   fantasai: ::placeholder and :showing-placeholder
   <florian> a bit verbose, but otherwise I like that
   Tantek: we also have :autofill that Mozilla and WebKit have both implemented
   Tantek: I think we have direction of simpler, shorter, thing being the
           pseudo class
   dbaron: Gecko has no auto-fill pseudo class
   <tantek> sorry - I misspoke - I assumed the bugs had been fixed/implemented
   <tantek> https://bugzilla.mozilla.org/show_bug.cgi?id=740979 and
            https://bugs.webkit.org/show_bug.cgi?id=66032

   * fantasai thinks we should break the topic and come back to it later
              when people have had some time to think
   <sylvaing> I think this is a poor decision. this shouldn't be designed
              in a one-hour meeting.

   Bert: If I use attr() function, take value of attribute, and put it somewhere,
         would the input element be in its showing-placeholder state?
   dbaron: no, only if it's showing the placeholder as a function of its
           rules for showing placeholders
   Tab: could do ... yourself using the styling
   Bert: assuming we generalize content property on pseudo-element to be
         empty, would it then be showing placeholder text?

   * fantasai ponders the situation of showing both value and placeholder
              simultaneously -- would :placeholder give appropriate styling
              then?
   <tantek> re: showing both simultaneously - that's an effect of a transition,
            not a state overlap
   <SimonSapin> glazou: ::placeholder and :placeholding
   <tantek> "placeholding" sounds awkward as a state
   * florian is not too sure about how transition works, but wonders why
             a transition on :placeholding::value {opacity:0} wouldn't
             allow the crossfade as well as the pseudo element

   fantasai: I think we need distinguish between placeholder attribute and
             idea of displaying placeholder text.
   fantasai: So the UA is capable of doing thing where it shows some kind
             of Ghost text where it helps user figure out what to type
ScribeNick: dbaron
   fantasai: placeholder attribute is one thing intended to be used in this way
   Tantek: I disagree on basis of HTML spec
   fantasai: but if you display in some other way it wouldn't be triggering
             placeholder pseudo-element... might trigger tooltip pseudo-element,
             but would be placeholder attribute's value showing up in some
             other pseudo-element
   SteveZ: Wouldn't that give me the way to do what smfr and I want to do
           by leaving the text there and absposing it so it wouldn't disappear?
   Tantek: I think you're making up a new feature.
   Tantek: As defined in HTML, what you're describing is not that.
   fantasai: Doesn't require it to show up in the input element, just says
             it's a hint.
   fantasai: Doesn't say it has to be shown inside
   Tantek: overlap case of showing up when you're typing is outside bounds
           of html definition
   Tantek: html definition reflects existing interoperable practice and we
           should make that work before doing other stuff
   SimonSapin: Steve, you can always use data-* attributes and select on them

   dbaron: do we need to update the resolution?
   Tantek: I object to the resolution from 15 minutes ago.
   RESOLVED: previous resolution-pair possibly retracted, discussion
             to be continued tomorrow
   Tab: Tomorrow want to get something somebody can *implement*
   <sylvaing> well, we've already implemented something....:)
   Tab: And then not mess with it anymore
   <sylvaing> Because discussions driven by arbitrary deadlines never need
              re-visiting?
   * florian thinks it is worth having a concrete proposal on the table,
             even if it is not set it stone, so that we can go home and
             think carefully whether it works, rather than go home and
             invent 12 different alternative ways to solve the same problem,
             and then try to figure out which one to keep
   <sylvaing> florian, we already have concrete proposals. some of them are
              even implemented. last, i don't understand the need to rush this.
              confusion and lack of consensus are not good reasons to speed up
   <florian> sylvaing, Point taken. It is a bit harder to read the mood of
             the wg via irc, so I'll use that as an excuse.

   <fantasai> TabAtkins, see also http://lists.w3.org/Archives/Public/www-style/2008Mar/0308.html

Peter: break until 4pm
   * florian wishes he was in Tucson

-florian

Backgrounds and Borders Revisited
---------------------------------
Scribe: TabAtkins

   ScribeNick: TabAtkins
   Rossen: We resolved to drop background-repeat:space from level 3.
   Rossen: But that's something that IE and Opera actually support.
   Rossen: I was looking at border-image-repeat, which we don't support.
   Rossen: So I'd like to separate the issue.  I'm okay with dropping the
           border-image-repeat, but not background-image-repeat.
   Bert: I think both of them do "the right thing" - the background is
         spaced to the edges, border-image is away from the edges.
         Both cases are "the right thing", but they're inconsistent.
   fantasai: That's probably alright.
   plinss: So do we still want to drop the border-image value?  Or mark
           it as at-risk?
   Bert: the more we keep, the better
   dbaron: the more we drop, the better
   Rossen: We have three impls, actually - webkit does background-repeat:space
           too.
   Rossen: If dropping it is done simply to move the spec forward, I'm for it.
   Rossen: But I don't see a reason to drop the already-implemented part.
   fantasai: We could mark it at-risk
   plinss: And put the reasons in the spec.
   RESOLVED: Keep background-repeat:space, drop border-image-repeat:space.

Placeholder Styling Continued
-----------------------------
Scribe: fantasai

   <fantasai> Topic: Tab Atkins presents fantasai's crazy proposal from the
              break wrt placeholder styling
   <tabatkins> s/crazy//
   TabAtkins: Idea was to do the placeholder pseudo-class, do fill-opacity,
              and ignore the rest of it for later
   TabAtkins: Those two would solve all the problems we have right now.

   dbaron: How do you just "do" fill-opacity?
   dbaron: One of the questions wrt fill-opacity is, if we eventually do
           fill and fill-opacity for text,
   dbaron: presumably there's some tradeoff where in some cases we do the
           color property, and others use text
   TabAtkins: No, we just always use 'fill', and 'fill' defaults to 'currentColor'.
              SVG is already OK with adding a UA style rule setting it to
              black for SVG elements.
   fantasai: It would default to black, but initial value would be currentColor.
   <stearns> if we do weird things for :placeholder pseudo-class, will there
             then be an expectation that this hack should work for other
             pseudo-classes?
   dbaron: we don't even know if the new inheriting behavior of currentColor
           is Web-compatible.
   TabAtkins: Could fix it in 'fill' in multiple ways. Could use 'auto'
              as the initial value. If necessary.
   TabAtkins: But don't have to worry about 'fill' right now. Just have to
              know there's a path forward. And deal with 'fill-opacity' now.

   dbaron: If we don't do that model, and we have a different one where
           using fill+fill-opacity in some cases and color in others...
   TabAtkins: Is there a reason to do that?
   dbaron: Are we sure we can do the other thing compatibly?
   dbaron: Two models for dealing with fallback
   dbaron: One is fill always works, but defaults to color.
   dbaron: other is fill has a "pass" value that says, don't do any filling,
           just use color like you used to.
   fantasai: Ah, and in that case 'fill-opacity' wouldn't work.
   SimonSapin: What's the difference?
   TabAtkins: First one could be incompatible with Web, while second is not.
              Second prevents you from using fill-opacity in general, because
              if you use pass value, it fill-opacity wouldn't apply.
   dbaron: Also kindof odd to have fill-opacity but not fill
   TabAtkins: But plan to add fill soon.
   dbaron: Don't think it's high enough priority
   TabAtkins: Ok...
   TabAtkins: [...]

   TabAtkins: Alternatively, add foreground-opacity, which does opacity
              for my contents but not for me.
   TabAtkins: Reasonable thing people have asked for.
   szilles: Doesn't that fall out of composition?
   SimonSapin: That's only for backgrounds.
   fantasai: Seems somewhat reasonable, but I would be less comfortable
             doing that with a week's notice than adding just fill-opacity....

   Bert: I'm not sure what I want, but going back a step, because we were
         talking about placeholder.
   Bert: The :placeholder idea seems bad idea to me UI-wise
   Bert: Either should leave it to UAs, or alternatively go all the way and
         give people alternative ways to show it
   Bert: Don't have control over tooltip styling either

   fantasai: Just to go back a bit, one of my concerns with having both
             pseudo-class and pseudo-element is that authors will be
             confused when to use which one and how they interact.
             Because when there's only one, the cascade is obvious,
             but when both are there, rules intended to style the
             placeholder could interact in unexpected ways depending on
             which selector was used.
   smfr: Why add fill-opacity, avoids pseudo-element?
   TabAtkins: That and, it's useful generally.
   [Explanation of why opacity is desired styling of placeholders:
    it preserves having contrast no matter which colors/backgrounds author
    chose, while dimming the contrast slightly to distinguish from actual
    value]
Received on Friday, 15 February 2013 01:06:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT