[CSSWG] Minutes Telecon 2014-02-12

Charter
-------

  - Plh reported that we're on track for the charter extension.

New Regions WD
--------------

  - RESOLVED: Publish a new WD of Regions

Selectors Poll
--------------

  - There was heated debate on the validity of the poll to determine
      naming syntax for Selectors as the text of the poll was
      changed after about 130 responses to address concerns that
      people were responding to the presence of ! instead of the
      larger issue. No decision was reached as to if the poll can be
      used being mindful of the change in wording or if a new poll
      needs to be created.

Shadow DOM
----------

  - Naming a combinator for ident was discussed with suggestions
      including /ident, #ident, :ident, /ident/, and `ident`.  The
      group leaned toward /ident/. It was the groups opinion that
      this should stay in Shadow DOM and not move into Selectors for
      now.

Counter Styles API
------------------

  - The group discussed the implications of Xidorn's issue of return
      value for an empty string. Initial feelings were toward having
      it return initial value. TabAtkins then tested the
      implementation in Firefox and Chrome later in the call and
      said they were returning empty strings. The discussion will
      continue after more people can run tests.

Concept of Baselines
--------------------

  - It was decided this issue did not need telecon time.

::first-letter
--------------

  - Dbaron will write a proposal for what exactly counts as a first
      letter referencing unicode.

Grid Issues
-----------

  - TabAtkins indicated he's still working on the issues raised by
      SimonSapin

Inline box, atomic inline-level box, and transformable elements
---------------------------------------------------------------

  - The group agreed that the test at issue was incorrect because it
      assumes fragments apply where they currently don't.

Line box edge
-------------

  - Everyone agreed with tantek's proposal.

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

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Bruno de Oliveira Abinader
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Dongwoo Joshua Im
  Dael Jackson
  Brian Kardell
  Philippe Le Hégaret
  Peter Linss
  Edward O'Connor
  Christopher Palmer
  Matt Rakow
  Simon Sapin
  Dirk Schultz
  Alan Stearns
  Leif Arne Storset

Regrets:
  Mihai Balan
  Justin Erenkrantz
  Simon Fraser
  Brad Kemper
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Lea Verou
  Steve Zilles

Scribe: Dael

Extra Items
-----------

  glazou: Let's start
  glazou: As usual, any extra items?
  glazou: The agenda is pretty full, but if you have something we
          can retain for next week, that's fine.

  glazou: We have an item from tantek.
  <tantek> (hopefully quick, had one positive response from
           TabAtkins, no objections)

  ???: Is it worth doing a poll on the call?
  glazou: You mean selectors? I suggest we do that.
  glazou: I think the poll is invalid because it was changed.
  TabAtkins: As I said we know who saw it before the change.
  glazou: We're just adding items now, and I responded on the list.
  <SimonSapin> (TabAtkins, present it as two polls with separate
               results)

  glazou: So first extra item is the poll. Any others?

Charter
-------

  glazou: Can we have an update on charter extension? Before you
          said it would be ready before the F2F.
  plh: I think we're on track and don't expect any surprises.
  glazou: Any questions?

New Regions WD
--------------

  astearns: Just asking for a new WD. It's been 8 months since the
            last WD and there's been substantial changes so I'd like
            to publish.

  Bert: Is this the split we discussed at the F2F?
  astearns: Yes.
  Bert: Okay
  glazou: So you approve?
  bert: I do

  RESOLVED: Publish a new WD of Regions

  glazou: Given that it's a hot topic, let's insert the selector
          poll now

Selector Poll
-------------

  glazou: So TabAtkins publisher a poll about selectors. In short it
          was a question, do you prefer ! as the descriptor or :has.
  glazou: The problem is originally it was ! or has but after 130
          responses he changed the wording.
  glazou: Lots of people rejected !
  glazou: I think the new question is different and I don't think
          that we can infer anything because of that.
  glazou: SimonSapin suggested a new poll with three options, !
          :has, or ^
  glazou: So I think I reject the results of the poll.

  SimonSapin: I agree results are useless but I think TabAtkins
              should separate the results of the exit poll.
  TabAtkins: I can do first 130 of ! vs. :has and the rest as ^ vs.
             :has

  glazou: I don't think you can do that.
  TabAtkins: I think we have an overwhelming result.
  glazou: This just isn't the same question.
  TabAtkins: We've had 800 results and most of them picked the same
             answer as before.

  * sgalineau would love to discuss the issue instead of arguing
              about the polling
  <SimonSapin> sgalineau +1
  <dbaron> So if you polled two separate questions at different
           times, just report the results separately?
  <SimonSapin> dbaron, this is effectively what happened

  glazou: Taking my co-chair hat off, as a standards body we aim at
          doing things right and this isn't done right. We don't
          change the question in the middle of a vote.
  glazou: Even if it's only 10% that disagree with what you say is
          final results.
  TabAtkins: We're randomly sampling in the first place, so it just
             doesn't matter if they're two separate polls.

  <astearns> +1 to Tab's position. The results are useful considered
             separately. And they both point to the same result.
  * sgalineau thinks good polling is actually hard and we're
              unlikely to get anywhere near as much as we think from
              those things.
  * sgalineau "design by committee can't decide...let's do a poll!"

  <SimonSapin> TabAtkins, please give numbers for the separate
               results on IRC.

  bkardell: Since I'm on neither side of the discussion,
  bkardell: I think when they put the poll together what they wanted
            to gage wasn't if ! is confusing.
  bkardell: But they wanted an idea of if they like and indicator or
            like a combinator.
  bkardell: Overwhelming people picked the combinator.
  bkardell: We mixed two questions and I think TabAtkins was trying
            to act in good faith to see if we were asking the right
            question.
  bkardell: TabAtkins was saying we can derive that people want a
            combinator and we can do another poll.

  glazou: Reading the results, I think people were influenced by the
          ! and they were rejecting the !
  TabAtkins: And that's why the poll was changed to see if that was
             an issue.
  * TabAtkins is going to leave the call until people stop ignoring
              that we're random-sampling this stuff and so it
              doesn't matter.

  bkardell: Do we have a reason for not doing what TabAtkins Is
            suggesting?
  ???: Is this just avoiding work so we can prove what TabAtkins is
       saying or have another statement?
  bkardell: I think we can frame that poll with having just three
            options and that'll work.

  * sgalineau 15mn into a one hour call we're still arguing about
              the poll instead of the issue.

  glazou: I think it's painful that we can't discuss what a member
          did without him leaving.
  glazou: I'm going to stop now, but I'm disputing the results which
          we're going to specify.
  glazou: This is impossible to discuss.

  glazou: We don't have an update on Shadow DOM without TabAtkins.
  <TabAtkins> I'm still here, I just can't stand listening to people
              pretend that a poll is "biased" because they don't
              understand population statistics.
  glazou: I think saying I don't understand population stats is an
          insult.
  plh: I don't think that was the point, though.

  glazou: I'm saying the sampling isn't valid due to the change.
  sgalineau: I think there was an issue and we tried to resolve it.
             We can look at the issue and try and resolve the
             difference, but I think that we're running in circles
             and not making progress.

  glazou: TabAtkins for Shadow DOM?

Shadow DOM
----------

  TabAtkins: Let me pull the info.
  TabAtkins: First I'd like to see if we can finalize a named
             combinator.
  TabAtkins: I'm assuming that /ident is a decent syntax
  TabAtkins: It looks good to me and people in the thread.
  * fantasai doesn't like it
  fantasai: I don't think that /ident is good because that's usually
            punctuation.

  TabAtkins: It's usually just a character so I think a syntax in
             that pattern isn't a good idea. We have :ident #ident
             etc. and they're all a compound selector.
  TabAtkins: If we're going to have that, it should have punctuation
             at the beginning and end and follow the white space
             rules of combinators
  <TabAtkins> `foo`
  ??: I think a few people liked the idea of brackets.

  <TabAtkins> /foo/
  <fantasai> /ident/
  fantasai: We can just use that [above]
  <fantasai> /ref somethingorother/
  <SimonSapin> is '/ ident' the same as '/ident' ?
  <fantasai> no
  <TabAtkins> SimonSapin: No, it's not - ". ident" isn't the same as
              ".ident"
  <SimonSapin> ok
  <TabAtkins> SimonSapin: Whitespace is significant in selectors.

  TabAtkins: I'm fine with that. I like single slash, but 2 is okay
             as well.
  <astearns> I'm OK with either as well
  <fantasai> well, I guess we could define it either way :)

  hober: I realize we don't have single style comments in CSS, but I
         worry that using something close to C++ is confusing to
         authors.
  fantasai: It's a single slash followed by another slash, though.
  bkardell: We could also use backticks.

  <sgalineau> so fantasai would rather have something like /foo/
  <sgalineau> ?

  TabAtkins: I'm down with that. If the WG would like to resolve
             that's fine.
  fantasai: I'm still wondering if it should be combinator instead
            of a pseudo-class, but I haven't read entire thread.

  TabAtkins: Any other syntax suggestions?
  TabAtkins: backticks, slashes or pseudo-elements?
  * sgalineau caught up with IRC. Is OK with /foo/
  <bkardell> I am good with `foo` or /foo/
  * fantasai doesn't like backticks, they're too light
  * fantasai visually

  hober: This isn't strictly combinator syntax.
  hober: I'm just wondering do we want to allow for future CSS to
         allow author-defined custom items?
  TabAtkins: Possibly which makes the ident nice.
  hober: I'm not sure quite what exclusion there was but I'd rather
         avoid collisions between the WG and arbitrary definitions.
  TabAtkins: The way the F2F discussion went was - are technically
             allowed in HTML, the main space is ident-.
  TabAtkins: In CSS we use _ the same.
  TabAtkins: So if your media query has _ it's custom.
  hober: I'm fine with that for now.

  TabAtkins: This is a little ugly, but it works. We'll avoid
             collisions.
  TabAtkins: Since there's no additional syntax ideas, feel free to
             butt in.
  TabAtkins: Are we okay with / on both ends?
  TabAtkins: I'd like to resolve on that.

  hober: If we want a combinator in the future we can bring it back.
  fantasai: I'm not sure if using a combinator rather than pseudo-
            class is right, but if we're going with a combinator
            this syntax is good.
  <TabAtkins> /ref(foo)/ or /ref foo/ or whatever

  hober: I'd like to authorize TabAtkins to do what he needs, but
         I'm not sure I want to say this is the right thing to do.
  hober: Would a watered down resolution to allow you to spec be
         okay?
  TabAtkins: I spec'ed it. I want to know if the WG is okay with
             this direction.

  fantasai: Is this in selectors or shadow DOM?
  TabAtkins: Putting it in selectors.
  fantasai: I'd pref Shadow DOM and let selectors stabilize before
            shifting things into it.
  bkardell: Is that because you're not settled on named combinators?
  <glenn> +1 to what fantasai is saying

  fantasai: I'm not objecting per se but I'm not sure if this is the
            right idea. Selectors is almost implemented and this
            isn't qualified. I'd rather leave it in Shadow DOM so
            that it can be discussed more.
  fantasai: I don't want to mix this unstable thing with selectors
            where we're trying to take unstable things out.
  TabAtkins: As long as no one is actively objecting to syntax it
             is good enough for me for now.

  * fantasai let the shadow dom debate happen in the shadow
            dom...inion

  TabAtkins: In other words it sounds like we can move on,
  glazou: Excellent

Counter Styles API
------------------

  TabAtkins: Xidorn brought up interesting CSSOM questions
  TabAtkins: If you don't spec a descriptor in the style sheet, what
             rule should appear? Null, empty string, or initial
             value?

  glenn: Any implementation consistency?
  TabAtkins: None I've seen. @font-face has it implemented.

  dbaron: In many ways this is similar to properties, but there's
          no difference between initial value and unset.
  dbaron: My feeling is leave it the same as there's not a semantic
          difference.
  <dbaron> ... as the empty string

  fantasai: An interesting question is if you're doing the OM, do
            you want to rest, or preserve what the editor put in?
  fantasai: If there's no semantic difference it seems like things
            that are initial should stay set that way.
  TabAtkins: That's a separate but related question. You need to
             spec how these things serialize.
  TabAtkins: If you omit everything you would omit anything set to
             initial value too.
  TabAtkins: I think I like having it reflect initial value and on
             the serialization side specify you omit the scriptor is
             it's they're initial value
  TabAtkins: How does that sound?

  dbaron: One question is what do they do for @font-face?
  TabAtkins: I'm not sure. If we want to move on and come back to me
             I can test for 5 min and come back with data.
  TabAtkins: So let's do that. I'll come back in a few to tell you
             what @font-face does in chrome and Firefox.

  glazou: So we can move on?

Concept of Baselines
--------------------

  dbaron: I don't think this needs telecon time.
  glazou: Okay, good.

::first-letter
--------------

  dbaron: We had a long debate about what goes in ::first-letter.
  dbaron: The spec is specific when punctuation extends the first
          letter, but not what a first letter is.
  dbaron: ::first-letter applies to the first letter and also
          applies to digits, but doesn't mention anything else.
  dbaron: I think Gecko is the only one that does letter or digits
          and we occasionally get bugs were people expect it to
          apply to symbols.
  dbaron: I remember + and $.
  dbaron: It would be nice if the spec said what the first letter
          applied to.

  dbaron: There's one other quirk with this where we reference
          character classes we need to say what version of Unicode
          we're referencing.
  dbaron: Do people think symbols should be a first letter? Is that
          a bug in other implementations?

  fantasai: I think it's fine. The interesting question is do we
            just include the symbol, or the symbol and the next thing
  astearns: I would expect only the symbol.
  bert: That's not what I would expect.

  SimonSapin: Is this based on unicode categories?
  dbaron: That would be nice.

  hober: So we would blacklist a bunch of categories it doesn't
         apply to?
  dbaron: That may work, things like white space.
  fantasai: There's two levels of general classes in unicode, like
            higher and lower level ones.
  fantasai: I think we're only interested in doing high level ones.

  hober: Suppose unicode decided to add a new top level class. I'd
         rather have that included. I don't anticipate them adding
         white space.
  dbaron: I think if they add a new class, we want the old rules to
          apply.

  dbaron: Unless someone else wants to, I guess I should write a
          proposal?
  Rossen_: I think we're all agreeing.
  dbaron: Sounds like we're done.

  TabAtkins: Can we jump back?

Counter Styles API
------------------

  TabAtkins: In both Chrome and Firefox, unspecified descriptors in
             @font-face is the empty string.
  TabAtkins: I'll find a place to spec that.
  dbaron: Sounds good to me, given that it's what we do for
          properties.
  TabAtkins: Cool.

  TabAtkins: Can we get a resolutions?
  glazou: Comments?

  TabAtkins: For any unspecified descriptors in @ rules that font-
             face and counter style, they're in the OM as the empty
             string
  Rossen_: And this is what they do?
  TabAtkins: In Chrome and fireforx.
  Rossen_: Can you post that test?
  <TabAtkins> <!DOCTYPE html>
  <TabAtkins> <style>
  <TabAtkins> @font-face {
  <TabAtkins> font-family: foo;
  <TabAtkins> src: url(foo);
  <TabAtkins> }
  <TabAtkins> </style>

  TabAtkins: I did that and poked around for font weights.
  glazou: To be sure, it's when you query the explicit value of a
          descriptor?
  TabAtkins: That's a good question.
  glazou: I don't want to see it affecting a group.
  TabAtkins: CSSOM defines that and implementations differ.
  TabAtkins: Right now in chrome you see every property that could
             apply to any element show up.
  TabAtkins: That's likely because we're using the same
             implementation.
  glazou: Then I have no objections.

  rossen: Just a second, I'm getting on my computer to test it.
  TabAtkins: Do you want us to wait, or should we move on and you
             can report back?
  Rossen_: It'll take me two minutes.
  glazou: We'll come back when Rossen_ is ready.

Grid Issues
-----------

  SimonSapin: The biggest issue is how we define size of grid item
              and grid container.
  SimonSapin: Did I miss that in the spec, or is it not written?
  TabAtkins: I'm not ready to handle the issues. We're working on it
             and will answer as we get there.
  TabAtkins: We haven't made it there quite yet. Fantasai and I are
             working together, but were concentrating on flexbox
             earlier.
  TabAtkins: As soon as I can I'll do it, but if you want to message
             me privately with a time line you're looking at, that's
             okay.
  SimonSapin: We don't need more time for any grid issues.

 Inline box, atomic inline-level box, and transformable elements
 ---------------------------------------------------------------

  <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014Feb/0356.html

  glazou: I saw some mailing list answers on this
  TabAtkins: I think he has asking about the earlier decision that
             inline-elements are able to be transformed,
  TabAtkins: And dbaron had a separate question that was
             tangentially related about the spec only applying to
             elements related to CSS.
  TabAtkins: But that's different than the original question.

  dbaron: My question was that the spec isn't saying what we want it
          to and we should check that before we nit-pick.
  dbaron: So we said it shouldn't apply to transforms.
  many: Yes.

  ??: I think we want to say we can transform a box, not a
      collection of elements.
  TabAtkins: We only transform fragments that are the sole fragment
             created by a box.
  TabAtkins: They're the sole fragment by decision not happenstance.

  dbaron: Didn't we have a long discussion about how transforms
          apply to fragmented blocks at the F2F?
  ??: We did, but we didn't agree. The agreement was it shouldn't
      apply.
  * Rossen_ I'm good with the previous resolution

  dbaron: Seems bad that it stops applying as soon as you print.
  ??: That's a good question.
  dbaron: I'm okay with not applying to inline, but I'm not okay
          that it stops as soon as it fragments.
  TabAtkins: Starting with the base question, is the test wrong
             because spec says it shouldn't apply to inline?
  TabAtkins: In other words, the test is wrong. It currently assumes
             that fragments apply to inline.
  TabAtkins: Cool. So Gerard is right. We can take this later to
             decide what the definition of transformable elements
             should be.
  TabAtkins: So it sounds like that finishes the issue.
  glazou: Okay.
  <dbaron> seems like the spec ought to exclude non-replaced inlines
           rather than imply that any new formatting primitives (
           flexbox, grid, etc.) aren't transformable

  glazou: tantek you still there?

Line box edge
-------------

  <tantek> http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html
  tantek: I made a proposal to change that based on implementations.
  tantek: I got one positive reply, but I wanted to run it by the
          group before I edited.
  ???: It sounded good to me.

  <fantasai> +1 from me
  tantek: Thanks fantasai.

  glazou: Other opinions?
  fantasai: I think you want to run it by Robert O'Callahan.
  tantek: I already pinged him. I want to hear from other
          implementors.
  tantek: We (firefox) want to match webkit and want to make sure
          other implementors find it acceptable.
  Rossen_: It will mean a change for us, but I agree auto behavior
           makes more sense.
  <Bert> +1 from me, too

  glazou: Anyone from webkit?
  tantek: There's two changes, one webkit already does, one that's a
          logical consequence of the change.
  tantek: I don't think anyone does the second behavior yet, but it
          makes sense.
  Rossen_: I think that's fine. We can revisit later.

  glazou: No objections? You've got it tantek.

  glazou: We've got more time. Anything else?
  tantek: Did you do charter?
  glazou: Yes. It'll be under review shortly.
  tantek: I think the super-group discussion needs to continue.
  glazou: Yes, from time to time it's extremely bureaucratic.
  glazou: It lacks a bit, but I don't think all existing super-
          groups will be in the same category.
  glazou: They'll be quite different and I'm not sure the current
          prose will work for everything.
  tantek: I think glazou is having a positive impact and you should
          keep going.
  glazou: We needed something different. This isn't working.

  glazou: Anything else?
  glazou: Thank you and talk to you next week.

Received on Thursday, 13 February 2014 02:16:35 UTC