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

[CSSWG] Minutes Telecon 2014-02-19

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 20 Feb 2014 10:49:44 -0500
Message-ID: <CADhPm3spUmgkNiDe6kPTCkvX-KHO5QDYEzB6gY-_8HFHAa7uDw@mail.gmail.com>
To: www-style@w3.org
Writing Modes to CR
-------------------

  - RESOLVED: Changed text-combine-horizontal to text-combine-
              upright and take it to CR adding the note about
              feedback for mixed directions.

Follow up on Selectors subject indicator
---------------------------------------

  - RESOLVED: Use :has() as subject selector

Follow up on Shadow DOM
-----------------------

  - There was discussion about if Shadow DOM should use pseudo-
         element or combinator syntax.  Ultimately it was decided to
         defer on a resolution for syntax until next week so that
         everyone can mull over the implications of the various
         options.
  - There was also conversation about how to adapt to webapps likely
         adding a flag for opt-in/opt-out settings, but TabAtkins
         argued that it will be easy to make the adjustments once
         webapps finalizes their decision.

Charter Update
--------------

  - Plh reported that he thinks the charter should be able to go out
         next week.

CSS Syntax
----------

  - TabAtkins reported that he's received a lot of feedback on
         Syntax since the resolution to take it to CR so he'll edit
         the disposition of comments and come back to the group for
         another resolution.

Renaming fill-available
-----------------------

  - RESOLVED: change fill-available to fill

Namespace
---------

  - Fantasai will add text to namespace to allow the use of wildcard
         and also investigate getting the TR version updated.
         She'll then come back to the group for a resolution.

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

Present:
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Peter Linss
  Edward O'Connor
  Liam Quin
  Matt Rakow
  Simon Sapin
  Dirk Schultz
  Alan Stearns
  Lea Verou

Regrets:
  Glenn Adams
  Mihai Balan
  Bruno de Oliveira Abinader
  Brad Kemper
  Florian Rivoal
  Leif Arne Storset

ScribeNick: Dael

  plinss: Let's start.
  plinss: I saw the note about adding writing modes to the agenda,
          anything else?

  SimonSapin: I heard some things about transitions that happened
              this week.
  plinss: It went to CR, no one posted anything.
  glazou: I tweeted about it from the official Twitter account.
  plinss: Publication is being done by Bert, nothing else for us to
          do except work on test suites.
  plinss: But transitions are going.
  plinss: Anything else to add?

  plinss: Bert, we were just talking about the transitions, do you
          need anything?
  bert: No, everything is in process.
  bert: It's not online yet, maybe tomorrow.

Writing Modes to CR
-------------------

  plinss: Koji, you wanted to do writing modes.
  koji: Yes, I think fantasai and I think we're ready.
  plinss: Ok. Any objections to taking it to CR?

  * fantasai still wants to rename text-combine-horizontal, though.
  plinss: fantasai you had a note on IRC, should that be at risk?
  fantasai: Webkit implements -epub-text-combine,
  fantasai: MSFT implements -ms-text-combine-horizontal,
  fantasai: They're not compatible and don't follow spec, but the
            basic use-cases are compatible.
  fantasai: My only concern is I don't like the name. -horizontal is
            confusing.
  fantasai: Glyph horizontal only applies in text.
  fantasai: Horizontal only applies to horizontal text and this
            applies to vertical in addition to horizontal so it's
            inconsistent.

  koji: So are you happy to go to CR now?
  fantasai: I don't want to hold up the spec
  fantasai: I'm just unhappy with that aspect.
  plinss: Okay. Any objections?

  fantasai: Anyone else have comments on that issue?
  plinss: Suggestions for a better name?
  fantasai: I think John Daggett once suggested text-combine-upright.

  dbaron: I have one other question.
  dbaron: Do you think the stuff on mixed directions is solid?
  fantasai: Not as much as I would like.
  fantasai: I think it's poorly explained and confusing and may be
            wrong in some cases
  dbaron: I think I'm okay with that as long as we understand that
          implementation will lead to changes.
  fantasai: That will be helpful.
  dbaron: And lead to another LC in CR.
  fantasai: I think that will happen, but I haven't gotten anyone to
            help review.
  dbaron: I think implementation will help since the implementors
          will have to review.
  fantasai: I agree.
  plinss: Any notes in spec about that?
  fantasai: About it being unstable? No. I can add some.
  plinss: I'm not sure if we want to call it unstable as they won't
          implement. Maybe say in a note that we want feedback.
  plinss: But that's the point of CR.
  dbaron: It might be good to have a note that we're particularly
          interested in feedback in that section.

  plinss: Any other comments?
  fantasai: Anything else on text-combine-horizontal?
  [silence]
  plinss: Apparently not.
  fantasai: If no one cares, lets rename it.
  plinss: To text-combine-upright? Fine with me. Any objections?
  plinss: I think text-combine-horizontal is better from what you
          said.
  * Bert likes upright better, too.

  RESOLVED: Changed text-combine-horizontal to text-combine-upright
            and take it to CR adding the note about feedback from
            dbaron.

Follow up on Selectors subject indicator
---------------------------------------

  plinss: Let's try and resolve this.
  TabAtkins: I have the results written up.
  <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Feb/0441.html

  TabAtkins: So they were extremely clear. In both ! and ^
             comparison over 80% liked the combinator
  TabAtkins: Most of the reasons were what we had given.
  TabAtkins: The most common refrain is people preferred :has()
             because it was easier to understand.
  TabAtkins: They liked words instead of ASCII.
  TabAtkins: I think it's clear we should switch to :has() psuedo-
             class.

  plinss: Any other thoughts?
  fantasai: I can't object to consistent survey results.
  TabAtkins: We have over 1,000 responses so it's good size.

  dbaron: One thought I had was thinking about how one would
           implement and there's one strategy that wouldn't work for
           :has() , but I don't know if it would work for anything.
  TabAtkins: They should be equivalent.
  dbaron: With :has() you can have more than one downward chain.
  TabAtkins: You can do it with subject indicators.
  fantasai: That's why we banned it originally from :matches()

  plinss: To be clear, we're not excluding multiple :has()
  TabAtkins: I'd like to not. Theoretically there's no reason. This
             will be slow anyway so it will fall into complete, not
             fast.
  fantasai: Basic syntax, subject indicator doesn't allow branching
            of the selector, but :has() does allow it.
  fantasai: In the first case you'd have to allow :matches(), but
            for :has() you have it from the beginning
  dbaron: I think I'm okay.

  plinss: I presume we want to exclude nested :has()?
  TabAtkins: I'm fine either way.
  plinss: I'm not sure what it would mean.
  TabAtkins: You're reevaluating based on it's children. Their
             usefulness is extremely niche.
  TabAtkins: I don't want restrictions, but I'm fine with excluding
             if it's glitchy.

  bkardell: Does :matches() exclude nesting?
  TabAtkins: It does, but we need to fix that. We were planning on
             revisiting that based on last F2F discussion.

  plinss: Thinking about nested :has(). You can ignore the nested,
          but I'm not sure if that's relevant.
  plinss: Any objections to adopting :has() as the subject selector?
  * Bert No strong objection, but I think '!A > B' looks better than
         'A:has(> B)' though...
  * glazou is with Bert here but will not object.
  * fantasai too
  * leaverou same here, agreed with Bert.

  RESOLVED: Use :has() as subject selector

  TabAtkins: For aliases you can remove psuedo-class and use :has()
             for implementation

Follow up on Shadow DOM
-----------------------

  plinss: There's lots of talk on www-style. Let's see if we can get
          some traction.  TabAtkins, do you want to summarize?

  TabAtkins: We haven't made any major changes since F2F. We've
             shifted syntax of combinators from ASCII to /shadow
  TabAtkins: Based on fantasai's suggestion, it's now /shadow/ so
             it's more a combinator and avoids odd whitespace rules.

  TabAtkins There's 2 issues to resolve:
  TabAtkins: Original combinators are the equivalent of /shadow-all/
  TabAtkins: I added shadow which only selects children of shadow
             roots.
  TabAtkins: They wanted the shortest path that wasn't a definitive
             combinator.
  TabAtkins: However, later there was an objection from Elliott that
             using shadow to select children make you more dependent
             on other elements, but shadow-all lets you be more
             knowledge-free.
  TabAtkins: He thought it would make more sense for the shortest
             and easiest thing to be less fragile.
  TabAtkins: There's an author-concern about it being shorter and a
             usability concern about the child selection.
  TabAtkins: The preference concern isn't as strong. During matching
             it's cheap to move from an arbitrary element to it's
             host.
  TabAtkins: For matching purposes they're the same, but for
             updating purposes, then the child variant does have an
             impact.
  TabAtkins: I'm not sure how to fix this.

  dbaron: Did Boris and Jonas get a chance to respond to Elliott's
          response?
  <bkardell_> So the concern is related to a change to an element in
              the parent document requires reevaluation?
  <bkardell_> .foo /shadow/ .bar

  fantasai: On a related note, you sent an e-mail about if we should
            use pseudo-class or combinator syntax.
  fantasai: Based on an e-mail about this it seemed to be a psuedo-
            element is better then combinator so you don't have to
            select everything. You're in the tree and you don't have
            to have it be different for child vs descendant.
  fantasai: It's just a straight-up selector.

  TabAtkins: One argument against that, we'll still have super-
             descendant.
  TabAtkins: Even if we change child vs descendant, we'll still have
             another combinator. It feels off to have both.
  fantasai: One of the pieces is if it's a psuedo-element it would
            be strange you can use a child combinator and it would
            select descendants.
  TabAtkins: I'm not sure what it means and I think at that point
             you're using psuedo-elements as combinators.

  plinss: I think this is about my proposal. What I said was if you
          use pseudo-element to expose, it's a different model to
          expose.
  TabAtkins: That's another question.

  fantasai: What it means is shadow creates an access to one level
            down and shadow-all is the combination of all shadow
            trees.
  fantasai: So it's consistent to use pseudo-element for both.
  fantasai: And would be consistent with ::first-child if we allow
            selection inside.
  TabAtkins: That works regardless of approach.
  fantasai: But it's consistent.
  fantasai: My conclusion is it's better to use pseudo-element.

  plinss: So there's combinator, pseudo-element to pierce shadow
          tree or pseudo-element to expose the inside.
  TabAtkins: I think the third is a separate issue and dependent on
             what webapps does.

  TabAtkins: I don't think we should encapsulate when JS does it.
  hober: There was consensuses in webapps to add a flag to allow opt-
         in/out.
  hober: Putting aside the default, I think in CSS we should design
         assuming the flag exists.
  hober: I think we need to use the flag.
  TabAtkins: That's easier to resolve.
  TabAtkins: If they have the flag we should shut down completely.
             Then we do what plinss has proposed to expose specific
             things.
  hober: Right now you have /shadow/ etc. Suppose that was
         /custom ident/.
  hober: And if you wanted to expose the whole tree you could do
         that with /shadow/.
  hober: If there were particular things to expose you could do that.
  hober: I think syntax should be the same for public and private.

  TabAtkins: I'd rather not consume the syntax for shadow DOM. We
             didn't want to swap syntax just for shadow. I wanted
             /foo/ to be how we do combinators.
  hober: So /ident/ is how you get at stuff?
  TabAtkins: That's a viable way forward assuming we end up in that
             world.
  hober: I think we will be in that world. Let's assume the flag
         will be added. I think it could go either way, but the flag
         is the consensus.

  TabAtkins: We know what we would do if the flag exists and have
             plans, I think that's all we need to do.
  bkardell: Any way to add a note in spec that it may only select
            what's permitted?
  TabAtkins: We'll edit accordingly.
  hober: I'm just worried about resolving syntax before webapps
         makes a decision.
  TabAtkins: All our syntax plans have extensions for only exposing
             pieces.

  TabAtkins: So original conversation is pseudo vs combinators.
  TabAtkins: Since we already have child vs descendant, we shouldn't
             reinvent?
  fantasai: And there's no reason pseudo-element is inconsistent
            with how we use pseudo-elements elsewhere.
  fantasai: We don't need a magic combinator and pseudo-element lets
            you go into an alt tree.
  <glazou> +1
  * sgalineau doesn't like confusing what :: means for authors.

  TabAtkins: My only problem is pseudo matches nothing. It's a root
             of a pretend tree. It seems inelegant.
  hober: Maybe we need a new syntax for DocumentFragment where you
         can't apply property directly.
  TabAtkins: That's what combinator is trying, but it's got the
              inelegance of repetition.
  fantasai: Does shadow tree always have a root?
  TabAtkins: Yes.

  <sgalineau> Is the shadow root something you can set properties on?
  <sgalineau> It'd be awkward to be unable to set properties on
              E::shadow

  fantasai: Is it representative of a DocumentFragment thing? One
            happens to be style-able and the other isn't?
  TabAtkins: You mean first line?
  fantasai: Yes.
  TabAtkins: The first line is odd, but you can style it. It's a
             thing.
  fantasai: In the context of CSS you can style. In another
            environment you can grab fragment things. In that case
            pseudo would represent a fragment.

  TabAtkins: Idea: Rather than making named variants, what if we did
             the below.
  <TabAtkins> /shadow/ /shadow>/
  <TabAtkins> ::shadow>
  TabAtkins: I don't know if that look weird.
  fantasai: It does.
  <fantasai> ::shadow > foo
  TabAtkins: Weirder then that?
  <TabAtkins> /shadow >/
  fantasai: No weirder then that. It looks normal
  TabAtkins: This can also be taken to all combinators that are
             similar.
  TabAtkins: And you can do same with pseudo.
  TabAtkins: This lets you not create new names for ASCII
             combinators without exposing the weird of a non-
             existent pseudo element.
  TabAtkins: We're almost there.

  fantasai: I'm pretty confident that pseudo is the right way to go
  fantasai: I don't see any arguments on the other side. They're all
            against your previous ASCII combinator.
  TabAtkins: My main argument is it doesn't represent anything.
  fantasai: Not in CSS. It could be some API that returns either
            elements or fragment-y things.

  hober: I think this is not just shadow DOM.
  hober: They exist elsewhere and we should talk about it.
  TabAtkins: That would be similar to :attr where CSS doesn't care,
             but specialized things do.
  TabAtkins: We could have something that returns shadow root in JS.
  hober: You can picture passing this to query selectors.
  hober: It's not a pseudo element, it's a pseudo fragment.
  hober: I like the pseudo-element-like syntax, but not ::

  fantasai: I think the point is to use pseudo element syntax
            because it's like one and acts like one in the context
            of selectors.
  fantasai: If we do regions, you can do ::region and select the
            things inside regions, then you want to do ::first-line
  fantasai: These are all structurally similar.
  fantasai: It's not inconsistent with pseudo elements so we should
            use that.

  TabAtkins: I want to give this more thought to make sure there's
             nothing I'm missing, but I think it sounds good.
  TabAtkins: Can we defer until next week?
  hober: I'm also for not-resolving.
  plinss: That's fine for me.
  plinss: Progress of a sort.
  plinss: Anything else?

Charter Update
--------------

  <glazou> plh, Charter progress ?
  <plh> I didn't receive all the internal comments yet. Only
        comments are very minor and not worth mentioning here.
  <plh> I should be done with this by next call,
  <plh> And the charter should go out next week.
  <glazou> plh, ok thanks.


CSS Syntax
----------

  TabAtkins: I have a process question.
  TabAtkins: We resolved to take Syntax to CR, but in the few weeks
             since there's been a ton of feedback.
  TabAtkins: I've been replying as they come, but does that effect
             CR since there's changes between approval and now?
  fantasai: You'll have to edit the disposition of comments and get
             another resolution.
  TabAtkins: I'll void the previous resolution and treat this like a
             delayed LC.

Renaming fill-available
-----------------------

  fantasai: TabAtkins Did you want to rename still available?
  <fantasai> http://dev.w3.org/csswg/css-sizing/#width-height-keywords
  TabAtkins: Small issue, I've introduced several new words.
  TabAtkins: I've introduced fill-available which basically selects
             what's left at 100%.
  TabAtkins: Issue is we think this is a long name and instead want
             to call it fill.
  TabAtkins: If no one objects we'll just do the quick rename.
  * dbaron tries to remember what the original name proposal was
  <liam> How often will it be used?

  fantasai: We'll also looking for a new name for repudiate-floats.
  TabAtkins: We're not finishing this with that in there.
  * sgalineau repudiate-float is, like, TOTALLY AWESOME

  krit: We want to rename fill-available to fill?
  fantasai: yes
  krit: We use fill elsewhere and there might be issues.
  TabAtkins: It's just a keyword and the ones you're talking about
             is graphical and this is geometry.
  TabAtkins: I think context disambiguates.
  krit: I think there's others with geometry.

  plinss: Anywhere we'd use a shorthand?
  TabAtkins: No
  TabAtkins: Don't they use a purpose with min/max?
  krit: It increases size.
  TabAtkins: This is still be as big as it should be, which is
             reasonably close.
  krit: I just want to make sure there are no conflicts with
        background.
  TabAtkins: They won't collide grammatically.

  plinss: Do you want a resolution, or is this editorial?
  fantasai: We need a resolution.

  RESOLVED: change fill-available to fill

Namespace
---------

  TabAtkins: Separate question for the namespace spec.
  TabAtkins: I've been making edits about attributes selector and it
             turns out the grammar is worthless because doesn't
             allow wildcard subject.
  TabAtkins: The only place it's used is selectors and this part.
  TabAtkins: How difficult is it for me to edit the namespace spec
             to make it more useful?

  fantasai: What's the issue?
  TabAtkins: When selectors have a namespace you can have a selector
             before or after the bar.
  TabAtkins: However the namespace spec doesn't allow wildcard. It
             requires ident after the bar.
  TabAtkins: So no where can use the namespace selector.

  dbaron: Since when does it allow * for the attribute name?
  TabAtkins: Pseudo element allows wildcard.
  TabAtkins: You need to completely redefine the name of grammar for
             pseudo elements.

  plinss: It doesn't include the ident after namespace.
  TabAtkins: It doesn't include the * after the namespace.
  TabAtkins: If you look at namespace grammar, there's only an ident
             prefixed with namespace or with ident.
  <fantasai> http://www.w3.org/TR/css3-namespace/#css-qnames
  plinss: I'm looking at it and I don't see the ident.

  fantasai: Ah, you're looking at the ED
  fantasai: We never updated the TR version.
  <fantasai> http://dev.w3.org/csswg/css-namespaces/
  fantasai: I'm happy to add a wildcard thing.
  fantasai: I guess we need to publish.

  dbaron: So what are we adding?
  fantasai: Grammar for other specs to refer to.
  dbaron: You're sure that's all?
  fantasai: Positive.
  <fantasai> wqwname : wqname_prefix? [ ident | '*' ]
  <plh> http://www.w3.org/Style/2011/REC-css3-namespace-20110929-errata.html
        notes it is empty

  plinss: Let me backup, why are there differences?
  fantasai: I think we just never updated the TR.
  plinss: Okay. The TR is wrong.

  Action: fantasai update namespace and figure out what we need to
          put it on to TR
  <trackbot> Created ACTION-619 - Update namedspaces and figure out
             what we need to put it on to tr [on Elika Etemad - due
             2014-02-26].

  fantasai: It has no conformance implications to anyone anywhere
  plh: If I may, I think there's two parts that you'll need to
       publish again.
  fantasai: Yes, we'd need to publish a new edition.
  plinss: So you'll update and come back?
  fantasai: Yes.

  fantasai: Bert, did you publish the LC for backgrounds and borders?
  bert: I don't remember, maybe not?
  fantasai: You published the document, I'm wondering about the
            announcement.
  bert: Probably not then.
  <fantasai> Bert, would you like to do that or should I?
  bert: Should I or do you want to?
  fantasai: I'm happy for you to do it.

  plinss: Is that it for the week?
  plinss: Sounds like it. Thanks everyone.
Received on Thursday, 20 February 2014 15:50:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 20 February 2014 15:50:16 UTC