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

[CSSWG] Minutes Telecon 2014-01-22

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 22 Jan 2014 20:33:49 -0500
Message-ID: <CADhPm3vtQM1eQF4dAZ_j+_Ojt7ORRkVnE0QDmj=cb=6T-QBHwg@mail.gmail.com>
To: www-style@w3.org
January F2F

  - Everyone was reminded to add topics for discussion to the wiki.

May F2F

  - Glazou confirmed that the May F2F will be in Seoul and hosted by
         Samsung with the help of the W3C office.
  - He requested that working group members post their availability
         on the doodle he sent around so that dates can be
         finalized, hopefully at the January F2F.

Selectors 4 :has()

  - SimonSapin's proposal to add a :has() pseudo-class to Selectors
         4 was discussed.
  - The group differed on if the use of ! was confusing since it
         means "not" in boolean programming. A poll will be set up
         to gather more data on people's opinions.

Page Transitions

  - Glazou requested that a discussion of page transitions in CSS be
         added to the charter since he was hearing user demand for
         them in web-based apps.
  - RESOLVED: Add page transitions to the charter.

CSS 2.2

  - Bert reminded the group that tests still need to be written for
         some errata changes coming out of 2.1 before 2.2 can be
  - Some people have signed up for tests and Bert suggested that the
         upcoming Test The Web Forward would be a good time for more
         tests to be written.
  - Those that have signed up to create tests were also asked to
         make a list of the tests that were invalidated due to the
         published errata.

Fieldset Rendering

  - The e-mail from Robert O'Callahan regarding the interoperability
         problems with fieldset was discussed with the group
         debating on if the solution would require a new spec, or if
         it could be clarified within existing specs.
  - RESOLVED: Create a new spec for form control rendering with
         Rossen_ as an editor.

<ol reversed>

  - The group agreed that they wanted to offer reverse lists, but as
        the editor wasn't on the call, resolution was deferred until
        the F2F.


  Glenn Adams
  Rossen Atanassov
  Tab Atkins (IRC only)
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Bruno de Oliveira Abinader
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Philippe Le Hégaret
  Peter Linss
  Anton Prowse
  Matt Rakow
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Leif Arne Storset
  Steve Zilles

   Mihai Balan
   Chris Lilley
   Florian Rivoal
   Lea Verou

  ScribeNick: dael

  plinss: Let's get started.
  plinss: Anything to add to the agenda?
  plinss: F2F is coming quickly, please add topics to the wiki.
  plinss: I'd like to make progress on transforms, transitions, and

May F2F

  glazou: As I said, I pinged Samsung in Korea about hosting.
  glazou: I have confirmation that we can host in Seoul with help of
          W3C office.
  glazou: I posted a doodle for dates to the private mailing list
          and not everyone has answered.
  glazou: I'd like availability replies from everyone so we can pick
  glazou: Right now 19-21 May is the most available.
  glazou: That's a Monday-Wednesday.

  plinss: Do we want to give time for people respond on to the
          doodle, or should we do a resolution on dates now?
  glazou: We can do more time. Korean new year is soon, so it's not
          a problem if we give them a few days to decide.
  glazou: If that's okay by everyone, unless someone needs a choice

  glenn: I'd prefer we don't overlap with BlinkOn as well, so a
         different week would be good.
  plinss: Okay.

  glazou: I forgot to mention that immigration requires passports be
          valid for, I think, 6 months after.
  glazou: You'll want to check that soon to make sure you don't have
  * glazou will find the exact info about that
  * glazou CONFIRMED : Korean immigration requires passports to be
           valid 6 months after RETURN DATE

Selectors 4 :has()

  SimonSapin: So, as I explained on the mailing list I'd like to
              propose adding a :has() pseudo-class
  SimonSapin: I think there are equivalents in other systems where
              if you express with one you can use the other one.
  SimonSapin: I think this is faster and is the same for ??? and
  SimonSapin: The pseudo-class has utility where we can fix issues
              with indicators.
  SimonSapin: The ! has more issues then we have with it :has()
  SimonSapin: Any comments or opinions?

  bkardell: I believe it was originally has() and then morphed to !.
  bkardell: I think that was lack of an ability to agree on a child
            for has().
  <astearns> +1 to :has over overloading !

  bert: I don't think the parenthesis are good, you'd have nested
        brackets in parenthesis.
  bert: It makes it unreadable.
  bert: I like the use of the single ! since it means emphasis.
  bert: I'd like it better if you could underline the subject
  * glazou and Bert agree AT LAST :-)
  * BradK is not a big fan of the functional notation inside

  SimonSapin: I agree ! means emphasis, but in a boolean context it
             doesn't work.
  glazou: I don't think it's a problem.
  glazou: I discussed with web authors a while ago and they don't
          deal with boolean.
  glazou: They liked the ! as a selector.
  <sgalineau> I have the completely opposite experience.
  bkardell: I had the opposite experience. I don't know if there's a
            way to collect information, but I wish we could.
  bkardell: I've run it past 50-75 people and they all think it
            means not.
  <sgalineau> +1 to bkardell
  <TabAtkins> Speaking from a lot of jQ experience, :has() is *very*
              easy to use and really easy to read.
  <bkardell> +TabAtkins comment re: it exists in the most popular
             library and is widely used for a long time now.
  <TabAtkins> ! also has some funky issues with regards to exactly
              what selector *arguments* it's allowed in.
  <TabAtkins> We need to allow it in :matches(), but shadow DOM's
              :host() selector doesn't make any sense.

  glazou: I agree with Bert's comment about ()
  glazou: It excludes the part, it is the subject at the end of the
          chain instead of the beginning.
  SimonSapin: () is inside nesting, but we've had that before and
              its been fine.
  SimonSapin: About being at the end, it's what we've always had so
  glazou: You didn't understand.
  glazou: If you had a chain of selectors inside a big selector, i.e.
  <glazou> !p.class:hover vs. p.class:hovr:has(..)
  glazou: I prefer the first one.
  SimonSapin: I don't see a difference
  * sgalineau finds the latter easier to read.
  <sgalineau> No controversy here.
  glazou: When you read it it works.
  glazou: I'm only giving my opinion here.
  <smfr> ! looks like "not" to me.
  * antonp reads ! as "not" too

  bkardell: I see people find the latter one easier, that's the has()
            one, correct?
  <bkardell> My question was which sgalineau was indicating.
  <sgalineau> bkardell, I prefer :has()
  <glazou> I think we already had that exact discussion about ! long
           ago and made a decision

  plinss: I'm hearing people on both sides, no clear consensus.
  plinss: How do we move forward?
  plinss: Straw poll, public poll?
  bkardell: I think public is more useful.
  bkardell: The constituency needs to know who says what.

  * Bert has a hard time believing that a significant number of
         users of CSS associates ! with not. You must be a
         programmer to be able have that funny association.
  <glazou> Bert +1
  <sgalineau> The ! is too ambiguous for too many people.
  <TabAtkins> Bert:A lot of CSS users are at least light programmers.
  <TabAtkins> But I can definitely set up a poll.
  <sgalineau> Bert, I don't know a single web professional who only
               writes CSS and does zero programming in some
               scripting language.

  glazou: Saying ! as a subject selector denotes a negation, we've
          never had the problem with !important.
  dbaron: We have that problem with !important all the time.
  glazou: I've never heard that.
  smfr: It does happen all the time.
  bkardell: I've had that experience as well.

  plinss: Looks like Tab was offering to set up a poll.

 [Strange noise interruption]

  plinss: Where were we?
  plinss: I think Tab was offering to set up a poll on the selector
  plinss: Let's do that, get more data, and come back.

Page Transitions

  glazou: I posted a question on www-style and some of you have
          contributed to that thread.
  glazou: I think it's time to consider these transitions.
  glazou: A few reasons this is needed. Mostly it's because some
          industries want to move to web based apps and want to do
          some things with those apps.
  glazou: One thing users require is nice transitions, though.
  glazou: Industry said they can't move to web based apps without
          page transitions.
  glazou: Users will react negatively without it so it's needed.
  glazou: I'm not saying we have to do this now or that it's CSS,
          but the discussion should be in our next charter
  glazou: I'd like the WG to agree on the fact that this
          conversation is in scope for next charter.

  * smfr notes http://msdn.microsoft.com/en-us/library/ms532847(v=vs.85).aspx#Interpage_Transition
  tantek: I agree this is in our scope and I think I can dig up a
          1999 proposal for transitions.
  tantek: It may be numbers based, but I'm happy to publish publicly
          to further conversation.
  glazou: We have things from you, Microsoft, animations, SVG, photo
          effects... I'm sure we can aggregate these proposals in a
          secure manner.
  glazou: I think now is the right time to discuss it.
  glazou: We have user requests, basically.
  tantek: Seconded.
  glazou: Any other opinions?

  * sgalineau wonders if there is anything that wasn't proposed in
              the 90s or done in DXImageTransform.
  <bkardell> seems logical that it be in the charter esp. if that
             doesn't commit that a CSS solution *must* come about.

  bert: Just a question; is this related to the Opera proposal of
        directional navigation?
  glazou: No. I suggested this independently and don't know what
          you're talking about.
  bert: It's a simple transition, next page can be left, right etc.
  glazou: It's not that. It's fading between source and destination.
  glazou: It's a visual fade from one page to the next.
  glazou: How do you do it? If you build a GPs app for autos, you
          want things, transitions, to be really cool.
  glazou: The industry won't use web-based apps if they're not cool.

  SimonSapin: That's interesting, but I'd like to see proposals on
              what a page is;
  SimonSapin: Is it new URL, or page generated by the page-break-
              after property?
  glazou: That's what we need to discuss, but we can't do that
          officially without it being in the charter.

  * leif I'm not aware of any Opera proposal, and ftr directional
          navigation is about navigating within a page, not
          positioning pages visually in relation to each other

  tantek: There's things we can reference like hypercard, there's
          transitions between card like swipe left, right, etc.
  tantek: This is more than 20 years old
  <BradK> html:next { transition: flip-left; }
  <dauwhe> ebook readers often use transition effects between
           "pages" (used in the "paginated" sense).

  glazou: Any objections, or can we add that to charter?
  <BradK> +1 to page transitions
  <bkardell> +1

  glazou: I hear no objections.
  bert: I can see lots of problems, but I'm not objecting to talking
        about it.
  glazou: I'd like to be able to just talk about it in the charter.

  RESOLVED: Add page transitions to the charter.

  plinss: Can we go another step, does anyone want to work on this?
  glazou: I do
  tantek: I can at least dig up my old draft, I think it was in
          member space, which will make it harder to find.
  tantek: But I can dig it up and I can just publish it to the
          public lists.
  tantek: It's not going to be modern, but it will help with
          historical context
  plinss: I'm sure it'll be a useful reference.
  plinss: Whatever we do should tie into shader.

  glazou: Since this is a charter edit, as soon as we start
          discussing it we should study the security aspects.
  plinss: Security will be fun.
  <glazou> Security IG will help

 CSS 2.2

  bert: Some time ago we discussed publishing an update for CSS 2.2
        and we discovered we need new tests due to changes from
  bert: People asked me to make a wiki and people signed up to make
        tests, but some of the errata don't have sign ups.
  <plinss> http://wiki.csswg.org/spec/css2.2
  bert: This is a request for people to again look at the wiki page.
  bert: If there's any topic you can write a test about, please do.
  bert: We wanted to publish an update months ago, but we're still
        waiting on tests.
  * Ms2ger would help out if tests were in web-platform-tests.

  bert: I have some people signed up; Arron, ChrisL, SimonSapin.
  bert: If any of those people are here, do you have tests?
  SimonSapin: I don't have tests yet, but I'm going to work on them.

  bert: Another idea I had was some tests could be written at TTWF
  bert: If people going would keep that it mind, it's a good
        opportunity to write the tests of CSS 2.2
  bert: Any ideas how to get more tests?
  * Ms2ger doubts anybody at testtwf has the expertise to write
           those tests
  plinss: Typically at TTWF there's an opportunity for people to
          solicit tests.
  plinss: I won't be there, but will someone be there to make this
  plinss: Anyone going to TTWF?
  <rhauck_> This will be the first one I'm missing, sorry :(
  bert: I'm going.
  dauwhe: I'm going to be there.
  plinss: Can either of you help?
  dauwhe: I'm new and the plan was to ask for GCPM tests, but I'll
          do what I can.

  plinss: My other question is there a list of tests that were
  bert: Not that I know of.
  bert: I don't think anyone has done that analysis.
  bert: There was an expectation that tests have changed, but no one
         found out which ones.

  plinss: Can someone do that analysis?
  plinss: Anyone?
  bert: Maybe those that said they'd write tests can look at
        existing tests in same area?
  plinss: That's a reasonable proposition.

  plinss: Anything else on CSS 2.2?
  bert: I don't think so. We just need those tests and I think we're
  SimonSapin: I think the errata for character encodings is
              incomplete, so I'll try and submit those tests
  plinss: Okay.

Fieldset Rendering

  plinss: It looks like this is under-speced and there's lots of
          variance between browsers.
  plinss: So do we want to spec it, are we okay with it as is, if we
          do spec where would it go?

  dbaron: Seems like this issues is bigger than fieldsets, though it
          may make sense to start there.
  dbaron: We may be the right people to work on it, for all that
          it's between HTML and CSS. I don't know.

  <tantek> Is this just for legacy? I mean, do any real world web
           pages actually depend on fieldset rendering?
  <tantek> My understanding is that the rendering is unpredictable
           enough that any actually "designed" web page doesn't
           bother with fieldset rendering because it is so

  plinss: Anyone else?
  Rossen_: I think part of the point, as far as it comes to styling
           it, it goes to us.
  Rossen_: Overflow, border styling should certainly come to us.
  Rossen_: I'm not sure if the rest should be CSS or HTML.
  plinss: I think there's overall coordination, but there are
          definitely styling issues.

  Rossen_: I was playing with different implementations and I can
           see the frustration of some implementations not honoring
           overflow: auto.
  Rossen_: How is the legend positioned, is it to box or to content?
  Rossen_: All these style issues we can spec.
  Rossen_: I can see how we can do extensions to overflow, but my
           opinion is CSS should be like the rest and if it supports
           scrolling, it should always do it.
  Rossen_: But these are things we should discuss.
  Rossen_: Are we prepared to discuss these issues now, or does it
           need more mailing list time?

  <BradK> Is there a shadow DOM for fieldset and label?

  tantek: Is this legacy, or is this actually used?
  Rossen_: My assumption is this is referring to ...you said legacy
  Rossen_: The reference in the e-mail is to WHATWG information, so
           I'm assuming this is current
  <bkardell> Seems like this could use more info/discussion on the
             list if folks are unclear about legacy/unused etc.
  plinss: It's part of HTML5 so people are still using it.

  tantek: What I'm asking about is fieldset rendering and my
          understanding is people turn of the rendering because it's
  tantek: Is this to fix that or for an actual feature?
  Rossen_: My understanding is there is frustration over a lack of

  plinss: I'm not sure we can spec legacy and I'm not sure we need
          new features, but we need to spec how this behaves.
  plinss: Other question is who wants to work on it, where should it

  Rossen_: My q is what is "this"?
  plinss: I guess there's 2 approaches. Look at all bits of fieldset
          and make sure they're addressed or start a new spec
  plinss: I'm not sure the right approach, but there's definitely an
          issue here.
  plinss: Thoughts?

  dbaron: I think there will need to be a new spec unless it all
          goes on HTML5.
  dbaron: I don't know.
  * krit so much complexity in CSS :)

  Rossen_: This is why I was curious if it was planning or component
           since component shouldn't be us.
  Rossen_: As far as the style Rob was frustrated at, I can see
           border having spec for fieldset handling and also
           handling for overflow
  Rossen_: We can put that in CSS. The rest, I don't see how we can
           do it.
  Rossen_: What is the component unless we go into what HTML is
           trying to do with position and size.
  Rossen_: We'll either define component model or won't. If we're
           doing component model, let's do it more holistically then
  <BradK> Define its structure internally as shadow DOM, then define
          a default style sheet for it once 'appearance' is turned

  bkardell: That would spec fieldset?
  bkardell: Part of the goal would be answering it more broadly?
            Fieldset would be one use case of the component?
  Rossen_: Right. If you go after the component and this would be a
           part of it, this would be easy. I'm not sure we're the
           right WG to do it.

  dbaron: I'm not sure this is component model stuff?
  Rossen_: What would it be?
  dbaron: Fieldset is a thing that exists and you spec what is there
          and how style effects it. If people want to implement as a
          component model that's fine,
  dbaron: But they don't have to.
  Rossen_: For one this the legend is always in a fieldset. That's
          already semi-component.
  dbaron: You just said it in prose.
  Rossen_: What do you mean?
  dbaron: What I'm talking about is spec like what you just said.

  plinss: So dbaron made a proposal for a spec of form rendering. My
          concern is if we do a piecemeal approach we'll still have
          interop issues.
  Rossen_: I'd be happy with that as a spec.

  plinss: Other opinions?
  Rossen_: Is this something you want to work on dbaron?
  dbaron: Not especially.
  plinss: If we're going to create a new spec, who will edit?
  Rossen_: I can volunteer to work on it.
  plinss: Anyone else?

  plinss: Any objections to the new spec?

  RESOLVED: Create a new spec for form control rendering with
            Rossen_ as an editor.

  plinss: I imaging Rossen_ wouldn't mind other people stepping up
         to help.

  <tantek> Aside: regarding page transitions, I think this is the
           prior art I was thinking of:
  <tantek> Regarding page transitions prior art in HyperCard, the
           "visual effect" command, documented with various options
           (e.g. dissolve, iris open, scroll left, wipe left, etc.)
  <tantek> And that should complete my actions for page transitions
           from this telcon. :)

<ol reversed>

  plinss: Tab made some edits, but I was concerned this had behavior
           that couldn't be addressed in counters or are people ok
           with that?
  SimonSapin: There's one part that can't be addressed, but I think
              it's okay because it's only a problem inside the UN
  dbaron: I think we'll want lists to function within counters.
  SimonSapin: I think CSS defines that,
  SimonSapin: That's why I wanted the edit.

  plinss: If we can't do a reverse list we're not complete. We need
          to expand the model to address that.
  dbaron: Probably. We should also consider being able to set a
          counter without creating a new scope.
  dbaron: I think we had an agreement about making some new
          additions a few years ago.
  plinss: TabAtkins isn't on the call today, unfortunately.

  SimonSapin: I think we have counter-set
  dbaron: We do have them? Okay.
  SimonSapin: Yes.

  plinss: I guess my question is do we want to work on reverse-
          lists? Do we want to be able to do that?
  plinss: Any objections?
  SimonSapin: I think what we have is fine unless we want to expose
              the selection behavior without using HTML.
  plinss: That's what I'm leaning toward. I'd like to be able to
          explain everything in the model we have.

  plinss: We don't have the people we need on the call to move
          forward, but anyone have objections to that?
  <glazou> not me
  plinss: I'll take that as no objections. Maybe we'll discuss at
          the F2F when people are together.

  plinss: That's the end of the agenda and the top of the hour.
  plinss: Thanks everyone and safe travels. We'll see you Monday 9am.
  plinss: Bye.

[After Call IRC Conversation]

  <TabAtkins> dbaron: Setting a counter without creating a new scope
              was defined a year ago, in Counter Styles, with the
              counter-set property.
  <dbaron> TabAtkins, ok, so we did add counter-set :-)
  <dbaron> TabAtkins, I didn't realize the counter styles draft had
           things other than counter styles in it.
  <TabAtkins> It defines counters, in general.
  <TabAtkins> Which are separable from lists.
  <SimonSapin> TabAtkins: isn't it in Lists rather than Counter
  <TabAtkins> Whoops, yes it is.
  <TabAtkins> Forget my justification from a second ago.
  <TabAtkins> The counter-manipulating properties are in Lists.
Received on Thursday, 23 January 2014 01:34:18 UTC

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