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

[CSSWG] Minutes Sydney F2F 2015-02-10 Part IV: Page Floats, @extend

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2015 17:50:38 -0400
Message-ID: <CADhPm3svVpLH3PR31DKLG5r1+qiZSLOu=dP--AuRNgzg9aRT8A@mail.gmail.com>
To: www-style@w3.org
Page Floats

  - RESOLVED: Remove exclusions and regions sections from page
              floats spec.
  - RESOLVED: johanneswilm added as editor.


  - TabAtkins brought his proposal for adding @extends to CSS to the
      group (proposal available here:
  - There were a bunch of follow-up questions to clarify his
      proposal and determine if it's a good idea. Some of the items
      discussed were:
        - Is only having placeholders enough functionality?
        - Will this effect or change querySelector?
        - Does this exacerbates the existing misunderstandings about
            writing CSS rules?
        - Is there a better name than @extend?
        - Can this even be implemented in a browser? And will it
            effect performance to do so?
  - RESOLVED: Make an editor's draft (with big red warning) to work
              on the problem, called CSS Style Rule Composition,
              shortname tbd, may or may not end up with a solution
              similar to @extend


  Scribe: fantasai

Page Floats

  johanneswilm: Currently spec is unmaintained.
  johanneswilm: Page floats is rule that says images/figures should
                go to the top, could also say they go to the top in
                certain circumstances in some cases, to bottom in
  johanneswilm: Right now the spec that exists for it has Håkon as
                editor, and hasn't been working on it.
  johanneswilm: It contains page floats, but also exclusions,
                regions, etc. that others are working on.
  johanneswilm: I'm proposing for me to join the editorial team for
                this spec.

  tantek: Did you talk to Håkon about it?
  johanneswilm: Will try to engage with him, and everyone in print
                sector e.g. AH, PrinceXML, vivliostyle.
  johanneswilm: Our goal is to create a JS polyfill to get this
                functionality in browsers.
  johanneswilm: Getting browsers to implement was not successful.
  dino: Printing might be a narrow use case, but books are not.

  <zcorpan> I think håkon now maintains https://books.spec.whatwg.org/
  <tantek> zcorpan: it looks like https://books.spec.whatwg.org/ has
           not been updated in over 2 (almost 3) months.
  <tantek> and https://books.spec.whatwg.org/ does not appear to
           mention page-floats
  <astearns> tantek: https://figures.spec.whatwg.org/
  <tantek> only thing that books whatwg spec appears to affect
           re: floats is float: footnote
  <zcorpan> https://figures.spec.whatwg.org/#page-floats
  <tantek> thanks astearns zcorpan
  <tantek> https://figures.spec.whatwg.org/ appears to not have been
           updated since 2014-09-30
  <tantek> that is - not updated 4-5 months
  <tantek> https://figures.spec.whatwg.org/#page-floats

  johanneswilm: Dunno why it wasn't implemented.
  fantasai: Because it's vastly underspecified.

  Rossen: You mentioned a bunch of things.
  Rossen: What exactly did you want to take over, just page floats?
          Exclusions? Something else?
  johanneswilm: This is CSS Page Floats. We think that's what it
                should be about.
  johanneswilm: Exclusions, regions, I don't want to work on it.
  johanneswilm: I understand it's being worked on elsewhere.
  Rossen: Path forward we had agreed on was that exclusions is a
          module that provides specification on what happens with
          exclusion areas.
  Rossen: How these are positioned is not up to that spec, only
          about propagation of the geometry.
  Rossen: Doesn't deal with layout.
  Rossen: Are you also planning to work on exclusions, or just
  johanneswilm: Need to investigate underlying fundamentals.
  johanneswilm: The idea is not to talk about it here.
  johanneswilm: Want to make it very simple to start with, so just
                rectangular floats that go up or down.
  johanneswilm: And then in discussion with other projects that work
                with this, try to see what direction they want to go
                with it.

  Florian: To be clear, exclusions and regions in this spec are not
           what we call exclusions and regions. They are howcome's
           counter-proposals to.
  johanneswilm: The counter-proposals, we don't really need them in
  dino: Can we remove them?
  dino: It's obviously confusing
  <tantek> agreed, remove them

  RESOLVED: Remove exclusions and regions sections from page floats
  RESOLVED: johanneswilm added as editor.

  dino: Webkit has been interested in implementing this for awhile,
        for pages/columns in browser, for our ibooks product.
  dino: You don't have to ask just printing companies.
  johanneswilm: Sounds great
  johanneswilm: Want to work together with everyone who wants to
                work on this.
  johanneswilm: Want to have a specification that everybody can be
                proud of.

  tantek: Do you have an approach in mind for keeping in sync with
          Figures spec?
  johanneswilm: We will be talking to howcome and find out what is
                possible there.
  johanneswilm: He also has his own idea of exclusions and regions,
  johanneswilm: and first-letter caps.
  johanneswilm: Idea is not to import another idea, but we want to
                try to incorporate as much as possible with howcome.

  ChrisL: Anyone implementing Figures?
  dauwhe: I'm not aware of anyone. Will have more info after I visit
          YesLogic this week.
  dauwhe: howcome isn't involved in the WG anymore, this is the
          group that has to decide what goes in the spec.
  ChrisL: Great that there's not just a totally-separate-from-
          browsers group doing this on the side.

  Rossen: For other browsers that have experimental implementations
          of exclusions, I don't want to all of a sudden drop them
          and start working on page floats and stop working on
  johanneswilm: I don't think they are exclusive.
  johanneswilm: If anyone has written thesis in laTex.
  johanneswilm: You can write a directive that all figures and
                captions go to the top.
  johanneswilm: This is the same. You define, once, where everything
  johanneswilm: If you want more graphic art of making books, you
                want to decide where each figure goes, where each
  johanneswilm: Text goes around in funny ways.
  johanneswilm: No computer can do that automatically.

  cameron: Is it in the spec to go to a new page or a named page?
  johanneswilm: Right now just want to get a simple specification
                that is similar to what is shipping in these
  johanneswilm: That said, there are many common things not
                implemented anywhere.
  johanneswilm: Floating things on other pages, for example.
  johanneswilm: Or float images all to a set of 8 pages that are in
                color when the other pages are black and white.
  johanneswilm: We can grow as far as we need to, but not more than
                there is implemented.
  dauwhe: That's a significant use case for us.


  <ChrisL> https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html
  TabAtkins: One of the most consistently popular parts of SASS is
             @extend rule.
  TabAtkins: Massive update.
  TabAtkins: dbaron about 2 years ago suggested something that had
             almost exactly the same shape as @extend, but with less
             convenient syntax.
  TabAtkins: Suggested just using @extend, that's what people are
             used to.

  TabAtkins: Here's a proposal to add @extend to CSS finally.
  <TabAtkins> http://tabatkins.github.io/specs/css-extend-rule/
  TabAtkins: Somewhat trivial example, but large corpus of examples.
  TabAtkins: Say you have a bunch of styles for a .error class
  TabAtkins: Later you realize you need to make a really serious
             error class.
  TabAtkins: Same styles, but make it red and bold as well.
  TabAtkins: There's ways to do this now, have to make all markup
             using seriouserror class also have error class.
  TabAtkins: Need to track in HTML.
  TabAtkins: Also in DOM manipulation.
  TabAtkins: Add and remove together, fairly error prone.
  TabAtkins: An alternate way is that in CSS every rule that has .
             error, also have a .seriouserror selector.
  TabAtkins: Also not great, because have to duplicate every single
  TabAtkins: Also maintain that as you remove selectors.
  TabAtkins: Lots of potential for typos.
  TabAtkins: Not good solutions to handling this kind of subclassing
             of widgets in CSS.
  TabAtkins: @extend rule captures this concept
             .seriouserror {
             @extend .error;
  TabAtkins: Means that every element to which this style rule
  TabAtkins: also matches the .error class.
  TabAtkins: Draft as it allows everything.
  TabAtkins: e.g. use :not()
  TabAtkins: Would be fine to restrict to feature selectors: tag
             names, classes, attrs, IDs, stuff that's in the DOM.
  TabAtkins: There are potential use cases e.g. :hover, but that
             makes it much more complicated.
  TabAtkins: That's basically it.

  TabAtkins: If you're not familiar with how insanely useful this
             has been, I suggest you just ask on twitter. "How
             useful is @extend?" You'll get "OMG, so useful, why
             aren't you doing it yet?"
  TabAtkins: Implementation-wise I have no idea.
  fantasai: Compound or complex selectors?
  TabAtkins: Compound selectors only.
  TabAtkins: Don't think it's worth the complexity.
  fantasai: Agree, just want to be clear.

  TabAtkins: @extend rule might make an element match more rules,
             which might themselves have @extend;
  TabAtkins: Shouldn't be a big deal, but a large number of chained

  dino: Loop?
  TabAtkins: Can't subtract features.
  TabAtkins: No loops.
  TabAtkins: No specificity issues.
  TabAtkins: Just behaves like it also has the .error class.

  dbaron: Are you matching specificity of seriouserror or error?
  [fantasai makes tab write on the board:
        #serious-error { @extend .error; }
        .error { color: blue; } ]
  dbaron: Is color: blue class-specific or ID-specific?
  TabAtkins: class-specific
  <dbaron> TabAtkins says that with #seriouserror { @extend .error }
           .error { color: blue} the specificity used for color:blue
           comes from .error

  glazou: OM to represent @extend?
  TabAtkins: We discussed this in the past, we'll add .cssRules on
             the stylerule interface.
  cameron: Does this work across style sheets?
  TabAtkins: Yes.

  cameron: Simpler mode is just single class names or single IDs
  TabAtkins: Answer is, I'm not sure.
  TabAtkins: SASS allows fuller model than what I'm doing now.
  TabAtkins: Might be possible to trim it down.
  TabAtkins: Could put as an issue in the draft.

  glazou: You allow only compound selectors in here? The other
  TabAtkins: Selector on the rule can be anything.
  roc: querySelector?
  TabAtkins: Unsure. Dunno what's useful.

  dino: I really like this proposal. Wondering whether just having
        placeholders is enough.
  TabAtkins: Placeholder selector is a concept introduced by SASS.
  TabAtkins: They use the % sign. It's just like a class, just
             impossible to match with any feature in the DOM.
  TabAtkins: The reason why this is used is so that when you're
             designing style sets you don't have to worry about
             accidentally clashing with stuff actually in the DOM.
  TabAtkins: Quite a bit of the stuff with @extend can be used is
  TabAtkins: You might have to start with .error, and then rewrite
             it to %error.
  TabAtkins: I would want to do more research if most use cases can
             be done with just placeholders/classes.
  fantasai: It does seem like placeholders would be a simpler model
            to have.
  dino: I think the placeholders will encourage people to code the
        way you said, to use semantic class names and use
        placeholders however is best for styling.

  dino: How does SASS do it?
  TabAtkins: They do it by selector-rewriting. This has a different
             selector specificity behavior; SASS authors think it's
  dino: I wonder if we could just have it as a copy, copying the
        properties directly in. I guess it applies the hash
  dino: What would be the problems with it?
  TabAtkins: @extend has a dual form with @mixin.
  TabAtkins: We could consider extending in the future.
  TabAtkins: SASS shows @extend is preferred by authors, so should
             do it first.

  dino: Awareness of specificity.. . it's a difference from the way
        normal CSS reads
  dino: shorthand, longhand.
  plinss: I'm not sure that you will be aware of the specificity.
  plinss: There could be other rules somewhere in the mix, there's a
  dino: Especially if .error extends from something.
  plinss: ...
  plinss: No predictability.
  TabAtkins: With a little bit of discipline, using mainly just
             placeholders, then will get into less trouble than that.
  dino: Yes, I like placeholders better.

  TabAtkins: Unless we allow @extend to affect querySelector, the
             placeholder won't match anything aside of the
             querySelector call.
  cameron: I think it might be useful to querySelector all my
  TabAtkins: I can see it'd be useful, might be issue.
  plinss: Really odd querySelector doesn't work, but also really
          weird that CSS affects the DOM

  [TabAtkins writes
            .foo { @extend: button; } ]
  TabAtkins: This will pull in the UA styles for buttons.
  cameron: Sounds neat, but internally we set some rules in the UA
           style sheet that really can't be applied to other
  cameron: Due to security, or we make certain assumptions about
           what elements they apply to.
  dbaron: Form controls probably should have been designed as values
          of 'display', but they're not.
  dbaron: So they require element-specific knowledge, and the Web
          depends on that.
  dbaron: If you put 'display: inline' or 'display: block' on a
          button, it's still a button.
  Florian: Have appearance property for that. The 'none' value has
           fair amount of interop, but other values work differently
           in different browsers.
  Florian: The buttonness of your button is not expressed in CSS.
  dbaron: Our buttons, for example, have 2 sets of borders instead
          of two.
  dbaron: If you @extend, you'll get one set but not the others.
  gregwhitworth: <select> control would be even worse.
  tantek: or file input.
  dino: I just wonder if we have a lot of power with a simpler thing.
  TabAtkins: This particular case is making custom element people
             happy as well. Would like to make see if we can do
  dino: Really? Custom element people want to copy platform
        controls? What?

  dbaron: One of my bigger concerns about this.
  dbaron: I feel like a lot of developers misunderstood what CSS
          rules were, and this makes it worse.
  dbaron: Like what this thing at the beginning of it was.
  dbaron: I feel like this part of a mental model that is different
          from what they actually are.
  dbaron: Model is that selector is something that matches elements.
  dbaron: I think a lot of authors feel like they are trying to do
          something that's kind of like assigning the elements to
          some object oriented programming hierarchy.
  dbaron: And this kind of looks like that.
  TabAtkins: Yes, works similarly. Allows that kind of ideas to work
  SimonSapin: Even the name seems to say that class is something
              that exists in your style sheet
  SimonSapin: And when you have .error, and you extend the class
              with another class:
  SimonSapin: That's object oriented
  SimonSapin: but that's not what's really going on.
  SimonSapin: Class is one part of selector that adds the class.
  SimonSapin: The name 'extend' seems to come from a mental model
              that is wrong.
  <glazou> +1 SimonSapin

  dino: Pick a name that is not @extend
  TabAtkins: Don't want to change the name from SASS
  <liam> I'm also concerned people used to SASS will expect
         @extend to be 100% the same
  dino: ... [good thing]
  ChrisL: It's too late to change 'class'
  ChrisL: You'll see #, Oh that's just a hash tag.
  ChrisL: People talk about "calling a class".
  ChrisL: Those people will look at extends, and be even more

  fantasai: Maybe the approach to take is to start with placeholders
  SimonSapin: If we go to placeholders, is this equivalent to custom
              selectors proposal?
  SimonSapin: Because you have a selector that extends a
              placeholder, and you can use that selector in other
  SimonSapin: Isn't that equivalent to having that placeholder
              expanding to that placeholder?
  roc: Difference in that you're declaring in one place all the
       things that are equivalent,
       h1, h2, he ... {
       @extend %heading;
  SimonSapin: How is that different from selector alias?
  TabAtkins: In terms of pure aliases, this is equivalent
             @custom-selector --heading h1, h2, h3, h4;
  TabAtkins: These are equivalent, yes.

  [glazou writes
          foo:not(.error) { @extend .error; } ]
  glazou: That's a loop, yes?
  TabAtkins: Yes.
  TabAtkins: hm, maybe have to do a loop-detection phase.

  roc: Two things aren't quite the same
  roc: With custom selectors you have to list all the extensions in
       one place.
  roc: With the @extend you can increase the list anywhere in the
       style sheets, which makes it much more useful.
  dbaron: You could have something that is outside of a style rule,
          but still has advantage of spreading around the style
  dbaron: Which is what I was proposing a few years ago.
  dbaron: Part of what makes me think it doesn't fit the model is
          putting it inside the style rule.
  fantasai: Can you summarize your proposal, dbaron?
  [People tell fantasai to go read it. While simultaneously taking
   minutes and trying to keep up with the discussion.]

  plinss: One thing, if @extend is inside the rule...
  plinss: I may have, to go back to earlier example, I may have 6
          different rules that apply .serious-error with various
  plinss: If I want to include .error, have to put it in all of them.
  plinss: When any of the others match, then only put it here.
  plinss: If I have 1 rule with .seriouserror:hover, and that
          contains @extend .error.
  plinss: It may have other selectors before .sersiouserror.
  plinss: If I put it in a rule that only matches sometimes.
  plinss: May be an advantage, but may be somewhat confusing.
  plinss: If you don't understand cascade/specificity correctly, you
          might get yourself into a confused situation.
  plinss: What I'm wondering is if it would be better to have it
          separate, not in a style rule.
  plinss: This selector is equivalent to this other selector.
  plinss: Then it applies to all rules and all style sheets.
  TabAtkins: Difference between this and @extend .seriouserror
             .error; is literally a matter of 2 characters.
  plinss: It's a big difference in behavior.
  TabAtkins: It's just syntactic.
  plinss: If you have .foo > .seriouserror
  plinss: Below that I have .bar > .seriouserror
  plinss: And in that one I didn't put @extend
  plinss: But if I have a separate rule that is @extend
          .seriouserror .error it works on both.
  TabAtkins: Yeah, same thing. You might have to have a separate
             rule that just holds @extend, but it's fine.
  plinss: Oh, nevermind.

  plinss: Going back to dbaron's point, I think there's a lot of
          people who don't understand how to compose style correctly.
  plinss: I think this just lets people who are doing it wrong do it
          wrong in more interesting ways.
  TabAtkins: Yes, but it also makes people who know what they're
             doing to have much more maintainable style sheets.
  plinss: I support better maintenance completely, but this feels
          really wrong to me.
  plinss: I would like to see different ways of composing style
          rules, rather than this.
  glazou: The problem is referencing a given rule from another rule.
  plinss: In my head, without really understanding this, I would
          rather it simply references the other rule.
  plinss: Would rather say "what I really wanted was this set of
          properties, plus all the properties from the other rule
          over there".
  plinss: Not by mangling what matches what.
  TabAtkins: People don't want that.
  plinss: Because they don't understand how to compose CSS.
  TabAtkins: You can have a bunch of style rules that apply style
             rules to .error in different contexts.
  TabAtkins: Referencing a block doesn't work well there.
  TabAtkins: I'm willing to let them be wrong if it helps them out.
  TabAtkins: It is extremely popular in SASS community, shows it's
             helpful to people.
  plinss: But it's a model that's wrong.
  TabAtkins: I'm willing to let the be wrong if it's helpful.
  <tantek> IRC aside: how *do* you compose styles correctly? anyone
           have a suggested "how to" guide? URL?
  <liam> [ tantek - I don't believe in right or wrong in this sort
         of thing anyway ]

  plinss: Going back to querySelector, that's really concerning
          because selector behavior which is different from style
  plinss: Doesn't fit in architectural model of the Web.
  dino: I would like to not change querySelector, otherwise I don't
        have any problem.
  dino: I think the point about CSS being able to change JS APIs is
        good, I agree.
  dino: I still like everything else.

  dbaron: I agree that extending one class with another is something
          we should do and is important to authors.
  dbaron: Authors end up writing 4 different selectors to build a
          hierarchy of stuff. So solving that point is important.

  dbaron: Wanted to ask question of what this actually does.
  dbaron: Suppose you have .article { @extend .section; }
  dbaron: And then .seriouserror { @extend .error; }
  dbaron: And then you have .section .error { color: whatever; }
  dbaron: This will match when you have <div class="article">
          <div class="seriouserror"></div></div>?
  TabAtkins: Yes.
  dbaron: Good.
  dbaron: It follows from the fact that I think this is important
          that we shouldn't limit it to just placeholder.
  dbaron: But I think a big part of my problem with it is the name.
  dbaron: It's the wrong mental model,
  glazou: More simulate than extend.
  TabAtkins: I would be somewhat unhappy if we changed the name.
  TabAtkins: But has advantage that [something about turning off
             @extend in SASS]
  dbaron: I don't believe that for a second.
  dbaron: All people whose pages are going to break aren't going to
          be happy.
  TabAtkins: That's SASS's responsibility.
  TabAtkins: Different name would avoid that problem.

  [glazou and plinss worries about nested selector matching]
  TabAtkins: You collect the @extend rules, iterate until stable.
  TabAtkins: Then in addition to DOM class list, you also look in
             the @extend class list.
  dbaron: That assumes the @extend rule is inside a selector that is
          just a class.
  TabAtkins: You match this, then you add this to extend this.
  plinss: TabAtkins hasn't actually written a selector matching
  * liam thinks @extend is closer to @isa in non-CSS systems fwiw,
         thinking declaratively rather than developerishly

  glazou: I'm afraid this is a feature for batch processors, not for
          dynamic browser. I'm worried about performance.
  TabAtkins: pre-processors can't implement this correctly.
  plinss: If you separate @extends out, then you can pre-compute it
  fantasai: That's syntactically equivalent.
  fantasai: It may not be the syntax you want, but they are
  fantasai: If I can write a perl script that rewrites it then it's
  glazou: Selector matching: You try to match all of the selectors
          in the CSSOM against the element that you have in your
          div foo .bar { ... }
          div > p > foo .section { #extend .bar }
  glazou: You run selector matching, then realize it extends, have
          to go run it again.
  <glazou> otherwise first rule will never match
  plinss: If you have a different syntax, you can keep the @extend
          rules in their own list and pr0cess them first and then do
          selector matching.
  fantasai: You could do that anyway. When you parse the rules,
            instead of storing @extend in the style rules list with
            the declarations, build up your separate @extend list.
  fantasai: They are syntactically equivalent.

  <dbaron> I still have no idea how we'd implement this in a
  glazou: I perfectly understand usefulness, but unsure how to
          implement this in a browser.
  plinss: Just explode out the selectors.
  TabAtkins: No, that won't get you the right behavior.

  dbaron: I think it's really useful for authors, but no idea how to
          implement it.
  <dbaron> I think selector variables are much more straightforward.
  <dbaron> maybe s/selector variables/custom selectors/

  plinss: I run into this problem myself.
  plinss: I'm not convinced this is the right way to solve the
          problem, but not sure it's the right way.
  fantasai: [...]
  <tantek> I for one like @extend

  dbaron: I had two proposals, one similar to selector variables one
          similar to @extend.
  dbaron: And I think I like TabAtkins's selector variables syntax

  roc: If you restrict it to the placeholders version.
  roc: Then you can treat it as a different syntax as aliased
  roc: And it's very clear how to implement that.
  SimonSapin: It depends on whether you allow using selector aliases
              before you define them.
  TabAtkins: %foo > .error { @extend %bar; }
  TabAtkins: Complex selectors are quite common in SASS like that.
             They have to use some heuristics for it, because can't
             do it quite correctly.

  TabAtkins: Can I have ED?
  fantasai: I don't hear agreement on the draft.
  fantasai: I don't even hear any ideas of what TabAtkins needs to
            do to fix it so that we all agree it's going in the
            right direction.
  fantasai: So I'm not happy with an ED.
  fantasai: But I also want us to tell TabAtkins what he needs to do
            to get there.
  glazou: My concern is that if we accept ED and then have a media
          storm if we reject or change significantly.
  plinss: Had the same thing with variables.
  glazou: Yes, and I would like to avoid that.
  dbaron: I'm nervous about making something an ED when more people
          in the room think it's not going to work than think it's
          going to work.

  <roc> hmm ... %foo > .error { @extend %foo; }
  <roc> div { @extend %foo; }
  <roc> so @extend is different from custom selectors because it
        allows defining recursive selectors

  [name bikeshedding]
  <tantek> css-as
  plinss: Call it maybe Style Rule Composition
  [random comments]
  [shortname suggestions]
  <tantek> css-subclassing
  <dbaron> css-bikeshedding
  <fantasai> css-composition
  <tantek> css-class-class

  RESOLVED: Make an editor's draft to work on the problem, called CSS
            Style Rule Composition, shortname tbd, containing current
            current contents but with a big with big red warning that
            it may change [perhaps drastically]

  <br type=snacks>
Received on Wednesday, 18 March 2015 21:51:06 UTC

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