W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-10 Part V: <custom-ident>, Flexbox, Form Control Styling, CSS Snapshot, CSS2.1, Obsoleting CSS3-Linebox

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:52:27 -0400
Message-ID: <CADhPm3sUXc3-y0O+8efsnY5rRA4e6hPhEaTwE03T_D4Z2rehXw@mail.gmail.com>
To: www-style@w3.org

  - RESOLVED: Exclude the global keywords from <custom-ident>.
  - RESOLVED: Pending edits, publish Values & Units as new CR.


  - The spec is close to a new release, just has a few more edits to

Form Control Styling

  - In order to keep the good discussion on the mailing list going,
      Florian will make a list of the proposals so far and everyone
      was asked to collect screenshots of form controls to style.

CSS Snapshot

  - RESOLVED: Produce the snapshot with list below, update vendor
              prefix policy. Group will review when finished.
                * Everything in REC
                * Animations L1
                * Backgrounds and Borders L3,
                * Cascading and Inheritance L3
                * Compositing and Blending L1
                * Conditional L3
                * Flexible Box Layout L1,
                * Fonts L3
                * Images and Replaced Content L3
                * Multicolumn Layout L1
                * Syntax L3
                * Transforms L1
                * Transitions L1,
                * Values and Units L3
                ** plus will-change and CSS3 UI once stable updates
                   are published to TR
  - Plan to incorporate intro material from CSS2.1 in next update
  - Plan to incorporate property indices/glossaries/etc. once we can
    generate them for an entire snapshot

CSS 2.1

  - RESOLVED: Add a note to every subsection of CSS2 pointing to
              drafts that replace those parts of CSS.

Obsoleting CSS3-Linebox

  - RESOLVED: Ask Chris to put an obsoletion notice on the current
              CSS3-Linebox on TR.


  Scribe: TabAtkins


  SimonSapin: We have an issue when <custom-ident> can occur at the
              same position as keywords, could be ambiguous.
  SimonSapin: Need to define how to resolve.
  SimonSapin: Right now the spec says that the first occurrence of
              something ambiguous is given to the keyword, and
              afterwards is <custom-ident>.
  SimonSapin: But that means you have to remember what you've parsed
              so far.
  SimonSapin: That's annoying to implement, and maybe surprising to
  SimonSapin: If you reorder things where order normally doesn't
              matter, it changes the meaning.
  SimonSapin: Another option is to restrict <custom-ident> based on
              what it can be ambiguous with.
  SimonSapin: For example, list-style-type takes either
              <counter-style> | string | none
  SimonSapin: And <counter-style> is <custom-ident>.
  SimonSapin: So if you specify "none", it can't be a
              <counter-style>, as it'll be ambiguous.
  SimonSapin: But that's easy.
  SimonSapin: In list-style, at the same position as you would have
              a <counter-style>, you might have "outside" keyword, a
              valid list-style-position value.
  SimonSapin: So here we should restrict <custom-ident> to not be
              able to be "outside".
  dbaron: So you'd restrict "outside" from list-style-type as well?
  SimonSapin: That's possible, but it's harder to maintain.

  TabAtkins: We explicitly rejected the "exclude keywords from all
             contexts it can be used", because that set is large and
             ever growing, and confusing to think about.
  TabAtkins: We also purposely moved away from the simpler "exclude
             keywords from the current context", because it still
             makes it hard to extend the set of keywords in the
             future; they might be used by authors.
  TabAtkins: We purposely moved to the current behavior, which
             matches animation, to avoid those problems.

  SimonSapin: Describe current animation behavior?
  TabAtkins: What the spec currently says - <animation-name> only
             claims unknown keywords, or known keywords that
             correspond to properties that are already set by
             earlier keywords.
  TabAtkins: So you can name an animation "forwards" as long as you
             also always specify the animation-direction part of the
             animation shorthand, and put the animation-name at the
  SimonSapin: That means in a context where order normally doesn't
              matter, sometimes it does and you can't.
  TabAtkins: Right.
  TabAtkins: All new grammars should always be positionally
  TabAtkins: The only reason we have this problem is old properties
             that get upgraded to <custom-ident>, so something that
             wasn't ambiguous becomes ambiguous.
  <dbaron> The values spec should probably say that (i.e., give
           advice for spec authors).

  TabAtkins: Are you okay with this, given that context?
  SimonSapin: Okay, I can live with this. I'd like to explore other
              options, but maybe in a later meeting.

  TabAtkins: Next is global keywords - allow or exclude? I don't
  fantasai: Weak preference for excluding. I don't think there's any
            reason to allow them, and they cause some problems.
  fantasai: And we already exclude them in font-family and
  fantasai: It's better to catch errors earlier, so it's a benefit
            to authors and just exclude it.
  TabAtkins: I'm fine with that - it makes it harder to add global
             keywords, but we don't do those often anyway.
  SimonSapin: I think it's arbitrary to exclude them  when not
              ambiguous, but meh.
  RESOLVED: Exclude the global keywords from <custom-ident>.

  SimonSapin: One remark about <custom-ident>.
  SimonSapin: The spec says that other specs must clearly say what
              keywords are excluded. Why normative?
  TabAtkins: Why not?
  (If we can put normative requirements on authors, we can put them
  on spec writers, too.)

  RESOLVED: Pending edits, publish V&U as new CR.

  ChrisL: Remember we'll need an up-to-date DoC to republish.


  <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html
  TabAtkins: Bug. Don't understand why Chrome and FF interoperably
             don't do the right thing. IE does the right thing.
             Please explain it all.
  fantasai: If you have an abspos flex container, it wraps to the
            window width, but doesn't shrinkwrap into it.
  fantasai: We think this is wrong, just wanted to check we're not
            missing something.

  fantasai: Issue about no-wrap is still open
  fantasai: and have some pagination stuff
  fantasai: then should publish.

Form Control Styling

  <fantasai> http://dev.w3.org/csswg/css-forms/
  TabAtkins: fantasai brought up form control styling.
  TabAtkins: Started a nice thread.
  TabAtkins: Started disagreeing on what is reasonable to allow form
             control styling.
  TabAtkins: Have a basic exploratory draft.
  TabAtkins: It writes up various proposals. We need more
  dino: Web controls are horrible on iPhone.

  ACTION: florian to make page of all form controls
  <trackbot> Created ACTION-673

  fantasai: So proposal is collect screenshots.
  TabAtkins: Two proposals so far, read and comment and throw out
             more ideas.
  TabAtkins: And really, want more screenshots. Especially from
             outside Android/iOS bubble

  Scribe: TabAtkins

  fantasai: Arron posted a proposal for a snapshot 2015.
  <fantasai> http://www.w3.org/mid/BLUPR03MB199E2D02A3708B7400C5108AD270@BLUPR03MB199.namprd03.prod.outlook.com
  fantasai: His proposal is:
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Feb/0200.html

  fantasai: We need to update the snapshot.
  fantasai: Introduction section needs reworking, change the
            vendor-prefix section.
  fantasai: But also need to decide what goes into the snapshot.
  Florian: dbaron and I have also helped him iterate on this
  fantasai: Proposal so far is everything in Rec,
  fantasai: Also animation, backgrounds, cascade, conditional,
            flexbox, fonts, images, multicol, transform,
            transitions, and v&u.
  fantasai: Some discussion about counter-styles.
  fantasai: And syntax.

  dbaron: Does anyone else implement text-decoration-3?
  fantasai: I think Apple does text-emphasis?
  fantasai: I'm guessing it'll wait to 2016, based on what I know.

  fantasai: Any other editors think their specs are ready?
  TabAtkins: There was a suggestion for the will-change spec. It's
             stable and widely implemented.
  tantek: I think UI meets the criteria too.
  TabAtkins: Did you drop all the weird stuff that nobody
  tantek: ::value/choices not yet, but will be dropped ASAP. Then
          it's all implemented stuff.
  fantasai: I say we leave it out until the new draft that drops
            those is up.
  tantek: How long to do it?
  Florian: Several bits need to be rewritten, so won't be published
           for a little bit.
  [some discussion about UI]

  fantasai: I'd like will-change to move to CR, if it's ready to be
            included in the snapshot.

  dbaron: Is Syntax a yes?
  dbaron: I'd like to see it in.
  fantasai: If dbaron says it should go in, I'll support that.
  TabAtkins: Everyone okay with Syntax in?
  [general assent/disinterest]

  <tantek> I don't understand the criteria being used
  <tantek> appears to be inconsistently applied

  SimonSapin: Anything we don't want that it's in CR?
  fantasai: Speech, because no implementations.
  fantasai: Text-decor not yet.
  fantasai: Writing-modes not yet.
  fantasai: Shapes and Masking are not in yet.
  TabAtkins: Shapes is in two implementations. Sounds like it
             should go in.
  astearns: I think Shapes is reasonably stable, but I'd still like
            another implementation.
  TabAtkins: So in or not?
  astearns: I dunno.
  astearns: Let's leave it out. I don't expect to see changes, but
            we'll see.

  dbaron: I think whoever made the list didn't go through FXTF.
  dbaron: Compositing, Masking, Filters, what's implementation
  TabAtkins: I think they're all in Blink/WEbkit.
  roc: Firefox doesn't do Masking. We do Compositing and Filters.
  krit: With exception of Blending, all other specs have partial
        implementations, but aren't implemented entirely.
  krit: So Blending should go in.
  fantasai: So, Arron's list, plus will-change and UI once they're
            updated, plus compositing.
  fantasai: Plus Syntax.

  <tantek> so we are including CSS3-UI?
  <astearns> tantek: once the edits are made, yes
  <astearns> tantek: same as with will-change
  <tantek> astearns, edits we agreed to in this meeting? because
           edits are going to be made for quite some time.
  <astearns> tantek: I thought you had a set of edits to make before
  <tantek> astearns, no, we already have a draft in the pipe to be
           published per resolution 2015-01-21
  <tantek> and I would assert event that draft is good enough to be

  Florian: Do we inline the intro chapters from CSS2? It has a nice
           introduction to CSS.
  Florian: If the snapshot is the introduction to stable CSS, seems
           reasonable to put that there.
  ChrisL: It turns "a list of stuff" into "a list of stuff plus some
          introductory material". Do people read it?
  ChrisL: Will the introduction be the same?
  Florian: Initially could be the same, but might change too.
  fantasai: I think we should do minimal stuff first. Update list of
            specs and interactions, update vendor prefixing, then
  fantasai: I think we should include the intro from CSS2 about
            "this is how property tables work, etc".
  fantasai: And a glossary of terms auto-genned from Shepherd for
            those specs.
  fantasai: All this latter stuff as a second publication.
  fantasai: And a property index auto-genned by Shepherd.
  TabAtkins: Sounds good. We can do the minimal stuff by end of Feb,
             additional publications pending interest.

  RESOLVED: Produce the snapshot with fantasai's list, update vendor
            prefix policy. Group will review when finished.

  <SimonSapin> plinss, maybe dev.w3.org/csswg/css/ should be an
               alias for the snapshot rather than 2.x, to match

CSS 2 updates

  fantasai: I think someone was proposing we should publish drafts
            where we remove sections of CSS2.
  fantasai: Unsure we can do that without a lot of overhead, and I'm
            not sure it's a great idea.
  fantasai: But we *should* put a note under every replaced
            subheading pointing to the replacing draft.
  fantasai: At some point in the future we can publish a skeleton
  Florian: Do we put a note pointing to specs when they're Rec? Or
           as soon as they exist?
  TabAtkins: As soon as browsers accept them as definitive.
  fantasai: CR, definitely. Earlier on a case-by-case basis.
  ChrisL: You're proposing a skeletonization.
  [discussion of zombie bodies of CSS2.1]
  [ChrisL describes Night of the Living CSS2]

  ChrisL: Apparently we have a bunch of errata to publish. I thought
          that's what CSS2.2 was about?
  ChrisL: Is the whole point of this to just point to the new stuff,
          why roll in errata in the first place?
  fantasai: I think there's some sections of 2.1 we don't have a
            replacement for yet.
  fantasai: Some have been replaced; their contents are still
            correct and can be used as a reference, but we should
            point to the newer reference.
  fantasai: So if we make changes, might as well keep them in sync.
  fantasai: But some sections have been completely gutted and
            redesigned, like syntax.
  fantasai: The warning should be more stringent and emphasize that
            the new reference is very important to look at.
  fantasai: We won't be maintaining any errata for syntax.

  ChrisL: Are there pending errata for 2.1 that need to be
  ChrisL: Where is that best going to go for people to notice it?
  ChrisL: The sections getting replaced should be the new stuff.
  Florian: If entire sections are wrong, just say "go look at the
           new stuff".
  fantasai: Part of the problem is that our errata maintenance
            process is unmanageable. It's too hard to publish our
            errata docs.
  fantasai: We can at least publish notes saying "look over here",
            so we should do that.
  fantasai: And also solve the errata problem, but that's separable.
  ChrisL: I just wanted to make sure the errata moved from the
          errata document to someplace people will actually look at
  SimonSapin: The editors draft contains the errata inline.
  ChrisL: And there's a note on 2.1 pointing to the ED.

  TabAtkins: So does anyone object to adding the notes to the ED,
             per fantasai?
  Florian: Is the criteria for drafts the same as the snapshot?
  fantasai: No. CSS2.1 might have a terrible section that's still
            being replaced by something better, but churning. It's
            still good to look at the new draft, versus the CSS2 def.
  fantasai: So if it's stable OR better, we should point to it.

  ChrisL: How to indicate it? People can deep-link.
  fantasai: A note on every subsection.
  TabAtkins: Yeah, that's probably sufficiently dense that you'll
             tend to see it.
  Florian: Bikeshed should have something for specs to indicate they
           replace something.
  TabAtkins: In time!
  SimonSapin: My list of replacement is my personal judgment of what
              people should look at for implementation.
  <SimonSapin> the list in question:

  RESOLVED: Add a note to every subsection of CSS2 pointing to
            drafts that replace those parts of CSS.

Obsoleting CSS3-Linebox

  <dauwhe> http://www.w3.org/TR/css3-linebox/
  TabAtkins: Tav from SVG keeps landing on this spec and it confuses
             him. Can we fix it.
  fantasai: We're going to redirect this to css-inline-3.
  fantasai: I think it was supposed to be published when we did the
            last draft of dropcaps, but looks like next draft.
  TabAtkins: So when's the timeline?
  TabAtkins: If it's gonna be this month, fine, otherwise do a note
             for now.
  dauwhe: Let's just do the note now.

  RESOLVED: Ask Chris to put an obsoletion notice on the current
            css3-linebox on TR.

  dbaron: I wish I'd at some point published the linebox edits as
          a WD.
  dbaron: No idea where it went now.
  dbaron: It's not in the draft repo as css-linebox.
Received on Wednesday, 18 March 2015 21:52:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC