- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2015 17:50:38 -0400
- To: www-style@w3.org
Page Floats
-----------
- RESOLVED: Remove exclusions and regions sections from page
floats spec.
- RESOLVED: johanneswilm added as editor.
@extend
-------
- TabAtkins brought his proposal for adding @extends to CSS to the
group (proposal available here:
https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html)
- 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
===== FULL MINUTES BELOW ======
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
others.
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
layout?
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
there.
dino: Can we remove them?
dino: It's obviously confusing
<tantek> agreed, remove them
RESOLVED: Remove exclusions and regions sections from page floats
spec.
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
exclusions.
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
goes.
johanneswilm: If you want more graphic art of making books, you
want to decide where each figure goes, where each
whatever.
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
implementations.
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.
@extend
-------
<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
selector.
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
applies
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
extensions.
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
only?
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
place?
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
placeholders.
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
fine.
dino: I wonder if we could just have it as a copy, copying the
properties directly in. I guess it applies the hash
serious...
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
.error.
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
buttons.
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
elements.
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
better.
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
out.
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
confused.
fantasai: Maybe the approach to take is to start with placeholders
only.
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
placeholders.
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
sheets.
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
selectors.
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
sheets
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
algorithm...
* 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
all.
fantasai: That's syntactically equivalent.
fantasai: It may not be the syntax you want, but they are
equivalent.
fantasai: If I can write a perl script that rewrites it then it's
equivalent.
glazou: Selector matching: You try to match all of the selectors
in the CSSOM against the element that you have in your
hand.
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
browser...
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
better.
roc: If you restrict it to the placeholders version.
roc: Then you can treat it as a different syntax as aliased
selectors.
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