- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Dec 2014 20:41:05 -0500
- To: www-style@w3.org
Agenda and Introductions
------------------------
-This discussion to set the agenda held no technical details.
CSS3 UI
-------
- RESOLVED: Add Florian as editor to CSS3 UI
- There was general consensus that the pseudo-classes listed
should only be in Selectors. They can move back into CSS3 UI if
it seems like it will make progress a lot faster.
- The pseudo-elements may be removed depending on if there's any
implementations.
- The values for text-overflow should be start/end instead of
right/left
::selection and Pseudo-Elements issues
---------------------------------------
- caret-color and text-shadow will be added as properties
- The color change when text is selected was discussed in regards
to what parts should change and what shouldn't, such as
underlines and text-decorations. fantasai will look into the
Microsoft implementation which was described as only the text
and background are selected.
- When text is replaced, it was suggested that the color should
always be different to indicate the change.
- When discussing the issue raised here:
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
it was agreed that the second option is the best choice and
offers the most interoperability. It is, however, very hard to
describe in prose, so anyone interested was asked to give it a
look to see if there's a way to improve the description.
- There will be more testing, specifically on IE, to see if it's
better to have color inherit through a cascading thing with
tree depth or having the inheritance go through the
::selection tree
===== FULL MINUTES BELOW =======
Present:
Tab Atkins
Takao Baba
David Baron
Bert Bos
Rick Byers
Dave Cramer
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau (on phone)
Daniel Glazman
Richard Ishida
Dael Jackson
Dean Jackson
Brad Kemper
Ian Kilpatrick
Peter Linss
Michael Miller
Shinyu Murakami
Simon Pieters
Keshav Puttaswamy
Matt Rakow
Florian Rivoal
Jacob Rossi
Andrey Rybka
Narumichi Sakai
Hiroshi Sakakibara
Simon Sapin
Dirk Schulze
Alan Stearns
Shane Stephens
Bobby Tung
Alan Turransky
Lea Verou
Ian Vollick
Greg Whitworth
Kazutaka Yamamoto
Steve Zilles
Regrets:
John Daggett
Scribe: dael
Agenda and Introductions
------------------------
[ This discussion to set the agenda held no technical details.]
CSS3 UI
=======
Status/Editorship
-----------------
florian: I was looking at this document that's been stagnating.
fantasai: I propose adding florian as editor.
rossen: That's what happens when you look at document.
glazou: tantek used to be editor. Did you ping him?
florian: Nope.
fantasai: He's not around.
glazou: No, he's not, but you should let him know. Learning about
it from a resolution isn't good.
glazou: So no objections?
RESOLVED: Add florian as editor to CSS3 UI, ping Tantek
CSS3 UI: selectors
------------------
florian: I'll dive in deeper, but while we're on it there is a
bunch of things about pseudo classes that are all in
selectors.
florian: I don't think they should stay here, they're better
spec'ed elsewhere. Can we remove duplications?
SteveZ: What's the status of them in selectors?
florian: Some are in 3, but all are in 4.
SteveZ: What's your expectation for progress? The main reason we
stick things is in for progress.
florian: It makes sense elsewhere.
SteveZ: But it's for making sure there's progression. It makes
sense in selectors, but if you need things to progress
they should stay.
fantasai: If CSS UI was close to CR it would make sense to leave
it in selectors, but I can't tell what would make it to
CR first. They both need cleanup.
SteveZ: So based on that, pull them out and you can put them back
if necessary.
fantasai: And they're already in selectors.
glazou: So the last copy on the TR is from 2012.
florian: The ED is more recent, but needs to be cleaned before
publication.
florian: For pseudo-classes the selectors text is newer.
florian: While we're in selectors, there's also pseudo-elements in
the spec. They seem reasonable, but don't seem to have
interest. Anyone care about what to do with them?
fantasai: What are they?
florian: Value choices, repeat item, repeat index.
fantasai: If there's no implementations we should drop.
Bert: It's hard to find implementation information because it's
not in browsers. I think Steven Pemberton is here and we can
ask him.
florian: That's my feeling. It's probably not something used, but
it's not inherently wrong.
Action: Bert find Steven Pemberton and ask him about
implementations
<trackbot> Created ACTION-656
fantasai: If there's none we should drop.
CSS3 UI: icon value/property
----------------------------
florian: We also have a content property extension. The value is
icon and lets you use icon which is a pointer to an image
and lets you use that instead of having it be a child.
florian: Right now it's described as applying to pseudo and
elements, but as far as I know it's not web compatible
for the content property to apply.
fantasai: We have implementations in the print world. It stays and
we need to figure out web compatibility.
florian: And why is it called icon?
fantasai: The idea is that it allows you to associate something
that represents that element.
florian: The ability to have a replaced element. That's reasonably
nice. That images are normally used on content and aren't
replaced make it hard to style.
fantasai: This wasn't intended to solve that use case.
dauwhe: Should we move this to generated content?
fantasai: Does anyone use icon?
...
fantasai: So we say this was a nice idea and we'll put it in the
list of CSS4 ideas. I'm surprised it's still there.
florian: It's marked as at risk.
CSS3 UI: text-overflow
----------------------
<andreyr> http://www.w3.org/TR/css3-ui/#text-overflow
florian: About text-overflow: there's probably a lot of issues.
Superficially it references CSS3 marquee. It probably
shouldn't. I don't know if we need a resolution for that.
Also when you use the two value variant which lets you
decide overflow at beginning and end.
florian: Currently it says left and right, should we change to
beginning and end?
Rossen: Should be start and end.
florian: Probably start and end, yes.
glazou: Basic support is implemented. 2 value syntax is only
Firefox and we don't have dbaron in the room. I'd love to
hear from dbaron.
florian: Sounds fair.
glazou: But in theory we should do that.
glazou: We do have consensus. It could be resolved, but he should
be here and he's late.
florian: There will be much more to come, but for this morning
we're good.
Bert: Can we go back to text-overflow? Where did you see
left/right/start/end?
florian: It says left/right.
Bert: Where? It just says ellipsis.
plinss: It uses both terminologies.
Bert: Ah, got it.
plinss: It's inconsistent. It's bad.
CSS3 UI: Miscellaneous
----------------------
smfr: There's many cases where it's (outline) is for drawing boxes.
florian: I think it belongs here.
smfr: I think box-sizing and text-overflow do not belong on this
spec.
fantasai: tantek leans toward objecting to a new co-editor.
glazou: There are no updates in 11 months and we need to make
progress or we'll drop it. I'd rather add florian.
glazou: Do you know where he (tantek) is?
fantasai: I don't.
glazou: Can you ask him to pay us a visit?
fantasai: Yes.
glazou: I have a question. The resize property...at least two
browsers don't implement it. Opera is listed as not
implementing because Presto. IE, are you planning to
implement?
Rossen: I think it's on our backlog. It's under consideration.
florian: It's not objected to?
Rossen: I don't think so, nope.
...
krit: To come back to resize, what was the suggestion?
glazou: I was just asking if IE would implement.
CSS3 UI: Status/Editorship (cont.)
----------------------------------
glazou: Anything else on CSS3 UI?
florian: Not for now.
glazou: You're planning new stuff?
florian: I'm starting with a cleanup.
fantasai: tantek says if florian wants to help he can start on the
wiki.
glazou: I think the group had consensus because we think it'll be
more productive to have him as an editor. I suggest we
stick to our decision. Is that okay for everyone?
[silence]
glazou: Okay. We have consensus minus 1 person. It's a good
consensus.
CSS Pseudo-elements: specifying ::selection
===========================================
fantasai: Okay. Let me get the spec.
<tantek> Good morning - I'm co-chairing the #social WG today and
tomorrow but will be on IRC here too
<tantek> ::selection latest info is in CSS3-UI issues wiki page
<tantek> https://wiki.csswg.org/spec/css3-ui#issue-30
<tantek> Still awaiting tests to answer questions raised in
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
<tantek> Until we have those tests, it doesn't make sense to try
again with a spec.
<tantek> Please capture any conclusions regarding ::selection in
this CSS3UI issue:
https://wiki.csswg.org/spec/css3-ui#issue-30
I'll read changes there afterwards - can't follow line-by-
line here in IRC right now.
<fantasai> http://dev.w3.org/csswg/css-pseudo
<fantasai> For the minutes:
https://dvcs.w3.org/hg/csswg/raw-file/9591381784e1/css-pseudo/Overview.html
fantasai: We have dbaron's e-mail. Let's project the spec.
<fantasai> dbaron's requirements were:
<fantasai> 1. Selection style shouldn't vary on least common
ancestor
<fantasai> 2. Default selection style should be representable by
UA rules
<fantasai> 3. Authors should override systems default style
<fantasai> 4. Background color and text color always cover
original color
<fantasai> 5. Authors can change within a particular element
fantasai: I did some browser testing. I don't think we can solve
the problem in #2
::selection: - Short Issues
---------------------------
fantasai: I'll go through and we can talk about individual issues.
fantasai: First issue is do we want to add other types of
selection i.e. spelling errors.
fantasai: Second is we don't have a way of distinguishing active
and inactive selectors.
bkardell: What is inactive?
fantasai: When the window is inactive.
fantasai: I'll skip 3 for now.
fantasai: Issue 5 is which properties are here. I think just color
and background color.
leaverou: Text shadow.
fantasai: I'll add that.
Action: fantasai Add text-shadow
<trackbot> Created ACTION-657
fantasai: Anything else we should be considering?
glazou: caret from CSS3 UI?
fantasai: Okay.
<leaverou> glazou: this caret?
http://lists.w3.org/Archives/Public/www-style/2011Nov/0772.html
bkardell: Would opacity make sense?
fantasai: That would add stacking, but we can use RGBA.
glazou: We don't have caret yet, but it will be proposed at some
point in future.
fantasai: So caret-color and text-shadow. Anything else?
Definitely not layout stuff.
adenilson: Maybe an issues link so we can open bugs in spec?
fantasai: Yes, I think an issues list makes sense.
fantasai: Point to Tantek's wiki
<tantek> fantasai - it's not "my wiki" - it's the CSS3UI issues
list on the CSSWG wiki
adenilson: I just found a typo.
r12a: Do we have to worry about Arabic joins being broken?
fantasai: Anything written here needs to handle discontinuity.
glazou: Is your idea to discuss how middle will be traded? Some
systems that's the case.
r12a: And I would guess CSS is a level above that.
smfr: Webkit allows you to style text-emphasis with the color and
text-fill color.
::selection: Representing Default Colors
----------------------------------------
fantasai: The next issue is right now in implementations: if you
don't specify a color then actual text is used and
background is transparent. If you don't specify either
you get system default. That means you can't have a
default UA style rule that represents system color, it
needs to be some kind of magic.
fantasai: Seems like everyone represents it that way.
fantasai: Blink, Gecko, and presto seem to do that. If IE doesn't
it's possible to change things for requirement #2. But
that's where we're at.
fantasai: If we did change it we might be able to use the
currentColor keyword so that behavior is representable.
I think compat might be an issue here.
::selection: z-index of selection colors
----------------------------------------
fantasai: It seems like the selection color and background is
painted right over everything else, but under positioned
things. That probably needs a bit more testing.
fantasai: It seems implementations redraw text decorations over
the highlight. I think if you're selecting text you
should just see text. If you specify decorations on the
selection of course you should see those. That the
background being opaque doesn't hide text decorations
seems weird to me.
fantasai: What do others think?
zcorpan: Does it look bad to redraw shadows/decorations?
fantasai: It does since they maintain original color.
fantasai: Let me give you a test case.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cu%3Eselect%20me%3C%2Fu%3E
fantasai: Black text with an underline. Select it and the text
becomes white, line stays.
fantasai: When you have decorations it might obscure text and make
it hard to read. Other people might have a different
perspective.
fantasai: This one has text-shadow.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22font-size%3A%20200%25%3B%20text-shadow%3A%20red%203px%203px%203px%22%3E%3Cu%3Eselect%20me%3C%2Fu%3E
fantasai: The coloring changes and text flattens to the two
colors, but the text decorations are wild.
smfr: This isn't how webkit works on a mac.
fantasai: I noticed, but no one else does that.
astearns: Firefox on mac is the same.
fantasai: If you do an alpha thing on top, showing through makes
sense.
fantasai: But in Linux it's repainted on top of that background.
<Bert> 4x
Rossen: What do you propose?
fantasai: That the background color of the selection obscures
text-decorations as if it's painted on top. So you draw
the selection background color over the text and repaint
the text.
Rossen: So you'd have shadows bleed behind the selection?
fantasai: If your selection color is opaque you don't see shadows.
Rossen: And if it extends beyond?
fantasai: You'd see it beyond.
fantasai: If you have a red blurry shadow on your text and you
select it, the section becomes the default colors. I
feel either you shouldn't see the colors or it should be
a color that belongs to the text selection.
Rossen: I think most of the...our selection is highly optimized to
be as cheap as possible for render so we don't re-blend
most of the things that we do for other types of changes
when we do selection.
Rossen: If this is something we need to worry about today I'm not
sure.
Rossen: Historically, our selection was just the selection
background with the text and that's it.
fantasai: I'll look at what you did.
<bkardell> Maybe it would be good to show visual representations
of these rather than verbal descriptions... I think it
should be like this picture, not this one.
::selection - Highlighting Replaced Elements
--------------------------------------------
fantasai: So. Next thing is for what I've tested: Require a
semi-transparent item wash over what you've selected.
Firefox and, I think, Opera just uses default selection
color. Webkit uses same color as selection background.
But if it's transparent you can't tell the replaced item
is selected.
fantasai: I took what they did and extended it: for non-replaced
content the UA should honor the specified color/bg,
but for replaced content they should do a wash of the
bgcolor, and if it's transparent you should use the
foreground color to create the wash.
fantasai: Replaced content can be foreground, or background, or a
mix. I think it's better that if you don't have a color
you can still tell what's selected and you're in the
same color scheme.
fantasai: I'll take comments on that. If you don't like it we can
use system colors for the wash. I don't know.
::selection - Area of Selection
-------------------------------
zcorpan: If you spec where the background should be painted and it
doesn't match the platform, that seems weird.
fantasai: We do require that... I have to say something about
where you're drawing. I say you have to cover the text
and may do more.
fantasai: I have a minimum set of requirements as to what you
cover which is the em-box of all the text. But you can do
more than that in order to match patform conventions.
fantasai: If we need looser wording I can do that, but having a
guideline makes sense.
::selection - Cascade
---------------------
fantasai: So let's go back to dbaron's issue now that he's here.
<dbaron> I presume the email you're talking about is
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
fantasai: There were 3 solutions to dbaron's requirements.
fantasai: First was each element is its own ::selection and if you
style them all they paint on top of each other. Problem
is if you have a background color with alpha they start
to stack as you get deep into tree.
fantasai: No one implements it and it's bad.
fantasai: Second two options were the selectable area of each
element belongs to the innermost element. What happens
if you have two elements styling the same thing? If you
have rules doing both how do you sort between the two?
fantasai: Browsers do solution B. Check the tree depth as most
important to decide color.
fantasai: Downside is suppose you style ::selection and
p::selection, if you select a <p> with a <span>, inside
the <span> the the ::selection style, not the
p::selection style, applies.
fantasai: We wanted the default style represented as ::selection.
But it would have to be :root::selection to get the
overriding correct.
fantasai: It seems where I tested (and I didn't test IE) all
followed B. So it's not incompatible and it's more
straightforward than C.
glazou: I'm confused. You have a p with a span inside. You said
you don't use the p::selection?
fantasai: Because ::seletion is shorthand for *::selection. They
both get assigned the ::selection rules.
fantasai: p has a more specific rule, but the span has its own
rule and within the span, we use its own rules.
glazou: Why did we want ::selection to not apply to the span?
fantasai: It was confusing to some people, who thought that
::selection set the default rule for the document.
When this was written with the various solutions,
there was there a way to have ::selection have that
expected behavior.
fantasai: But this behavior is consistent with how selectors
normally work, and we have interoperability on standard
behavior. So you cascade by depth then specificity.
<jcraig> why not just change the selector to "p::selection,
p *::selection"
dbaron: Do browsers match the details of option B? Specificity
stuff?
fantasai: Yes. I think so.
fantasai: Let me double check.
fantasai: I did the testing yesterday.
dbaron: I guess. Okay. I believe that. C was the crazy thing.
fantasai: We seem to have interop on B. I think that's what we
should go with.
fantasai: Trying to describe B is hard. Anyone interested should
read it and tell me if there's a better way.
::selection - Representing Default Colors (cont.)
-------------------------------------------------
fantasai: One requirement was system colors should be
representable as a UA. Right now if you don't set color
or background, we treat background as transparent and we
don't fall back to default.
dbaron: Is that interoperable?
fantasai: On many, but I haven't tested IE.
dbaron: Because that sounds weird.
fantasai: If IE does that we probably can't change it.
fantasai: But if it doesn't do that, then we're saved and we can
fix that.
::selection - Inheritance
-------------------------
fantasai: I think that's an overview of all the issues.
fantasai: Oh, one more. Each element draws it's own portion of the
highlight. When multiple elements conflict, the winning
one belongs to innermost after cascade.
fantasai: What do we want inherit to inherit from? So one option
was to inherit from the original. The other is
::selection pseudo inherits through its own trait.
fantasai: If you want to unset things, we have an unset keyword so
that's possible.
dbaron: That would need to be defined pretty carefully for
background inherit.
fantasai: Yeah. Now that I think about it color has to inherit
through ::selection tree. Initial behavior is inherit.
What is the value if it's not...
dbaron: You could define them as not having inheritance and just
cascade.
dbaron: Or with B: with cascade by tree depth, as long as it
happens before inheritance, you don't have to worry if you
say tree depth is part of cascading process. Then it is
moot.
fantasai: Right. Okay...
fantasai: I guess the question is which sounds worse. Making tree
depth a cascading thing or having inheritance through
::selection tree.
dbaron: I don't know and you can probably distinguish through
testing which is worth doing.
fantasai: I know. I have implementations for both, basically.
dbaron: If there's implementations for both I don't have a strong
opinion.
fantasai: I'll poke around with IE. I don't have any testing on
that yet.
CSS Pseudo-elements - Status
----------------------------
glazou: So are we done?
fantasai: I think that's all the issues.
glazou: Before we move on, I suggest we do the first coffee break.
fantasai: We could do pseudo spec overall, first.
fantasai: I bikeshedded the whole spec, I cleaned the first style
bits. There was a CSS OM section that I haven't deleted.
I didn't know what the WG wanted it there.
glazou: I don't know if it makes sense if you removed multiple
before/after.
astearns: Some of it does not.
glazou: I can take an action to review.
Action: glazou review pseudo spec based on edits.
<trackbot> Created ACTION-658
glazou: Anything else?
[15 minute break]
Received on Thursday, 18 December 2014 01:41:32 UTC