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

[CSSWG] Minutes Santa Clara F2F 2014-10-27 Part I: CSS3 UI, ::selection and Pseudo-Elements issues

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Dec 2014 20:41:05 -0500
Message-ID: <CADhPm3ssUgf4dKwnUavjWNL2vyzbQNbePD_dwwz38QSPmgBi5Q@mail.gmail.com>
To: www-style@w3.org
Agenda and Introductions

  -This discussion to set the agenda held no technical details.


  - 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
  - The values for text-overflow should be start/end instead of

::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:
      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 =======

  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

  John Daggett

  Scribe: dael

Agenda and Introductions

  [ This discussion to set the agenda held no technical details.]



  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
  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
  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
  <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
  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

  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
  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
  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?
  glazou: Okay. We have consensus minus 1 person. It's a good

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
  <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:
           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:
  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
  <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?

  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

  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
  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
  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
  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
  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
  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
  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
  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
  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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:46 UTC