- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2013 17:05:37 -0800
- 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 UTC