- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Jun 2014 09:00:26 -0400
- To: www-style@w3.org
Footnotes in GCPM
-----------------
- dauwhe gave a presentation on his progress regarding the
handling of footnotes. His slides are available here:
http://epubzero.blogspot.com/2014/05/footnotes-as-css-regions.html
- There was conversation about the progress dauwhe has made using
Regions and some suggestions about potential options to move
forward including the best way to create a placeholder for
where the footnote came from and exact things that footnotes
may need to do, such as be visible/invisible for certain
users and flowing into a new page.
- The group decided that dauwhe should use his progress to create
GCPM 4 and use that knowledge to backfill into GCPM 3.
- RESOLVED: ED for GCPM 4
CSS Scoping
-----------
- TabAtkins and fantasai presented their progress on CSS Scoping
and brought several issues to the group.
- The replacement for the @global selector was brought up with the
working group having differing opinions on what should be the
replacement and requested the addition of examples.
- The group also couldn't decide on a new name for ::content. They
narrowed the options down to two (::projected and ::light-
content) and will poll authors to make a final decision.
- RESOLVED: Add ">>" as an alias for the descendant combinator,
and change /deep/ to >>>
==== FULL MINUTES BELOW ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Adenilson Cavalcanti
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Daniel Glazman
Dongwoo Joshua Im
Koji Ishii
Dael Jackson
Philippe Le Hegaret
Chris Lilley (afternoon)
Peter Linss
Shinyu Murakami
Edward O'Connor
Simon Pieters
Liam Quin (phone only)
Andrey Rybka
Simon Sapin (phone only)
Dirk Schulze (phone only)
Alan Stearns
Shane Stephens
Jet Villegas
Steve Zilles (on the phone)
5 observers
Regrets:
Anton Prowse
Lea Verou
Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
Footnotes in GCPM
=================
plinss: Let's get started
plinss: Today is footnotes in GCPM
[link to slides from dauwhe's presentation:
http://epubzero.blogspot.com/2014/05/footnotes-as-css-regions.html]
dauwhe: Not everyone loves footnotes, but they're a big part of
publishing.
dauwhe: Here's a basic idea (slide)
dauwhe: We move the footnotes into a footnote area and place that
at the bottom of the page.
dauwhe: Sometimes they're not terribly simple.
dauwhe: My goal isn't to solve these problems.
dauwhe: So what happens in GCPM today, which is implemented by AH
and Prince, is that we have a special value of float
property that's applied to footnote content.
dauwhe: We find the area on the page with an @ rule.
dauwhe: This model seems to have some difficulties (list on slide)
dauwhe: We have an HTML problem where we need to content placed
where it should live, but there's a content problem for
location.
dauwhe: Everything is in terms of magic.
dauwhe: Lots of people have been saying why not use regions?
dauwhe: My goal is to see if this is a viable approach for
footnotes.
dauwhe: I've been trying out some things.
dauwhe: For moving the element, it's logical to flow it into
something. It's easy to make the reference marker with
the ::before pseudo.
dauwhe: The footnote area itself is more interesting since GCPM
depends heavily on paged media.
dauwhe: Trying to find a way to use @page and define the regions
we need is difficult.
dauwhe: So there's all sorts of proposals around to do this.
dauwhe: This seemed to be one that made sense to me (using Regions)
<astearns> @slot, required-flow etc. in
http://dev.w3.org/csswg/css-page-template/
glazou: This is what I wanted to do in paged media 4.
glazou: A footnotes area to me is the same as a regular area.
glazou: It does nothing special until you say there's a margin box.
It's a way of designing a page template that I feel is
right.
dauwhe: Footnotes are interesting because if there isn't one on
the page, you can't create the footnote area. Required
flow seems to be exactly what I want.
dauwhe: Of course we have issues with implementors using the flow
property to place the footnote region. Mostly of bottom by
default.
dauwhe: Avoiding all page floats seems a worthy goal since they
seem hard to define and don't have a lot of support
outside formatters.
dauwhe: Good news this seems to be easy to extend in the future to
support multiple streams of footnotes.
dauwhe: This isn't that common, but might be used in academic
circles.
dauwhe: This gives us a nice way to suppress footnote area.
glazou: The way footnotes are created and the relationship between
how they work is clearer. Here the mechanism is understood.
You can figure out what's going on.
dauwhe: We don't have to float the footnote element, we can remain
agnostic on floating the footnote and we can see what
implementors think on that. It's regions so people are
happy. Aside from performance.
* astearns suggests to people reading the minutes that the
performance comment was presented as a joke :)
dauwhe: Bad news is, this changes syntax from existing
implementations. I'm not sure that's a huge issue because
I expect they can tack on new syntax.
dauwhe: One issue with the regions approach is as you move the
footnote out you need to leave a marker and I don't know
how.
dauwhe: You can do markup with two layers of markup but that's not
particularly elegant.
dauwhe: I have a sense that this whole idea of having something
left behind when you move might be worthwhile elsewhere.
Rosen: Have you tried to move the section and leave a note?
astearns: I think the before and after are included so there's not
outside.
dauwhe: It would have been cool if it didn't get moved into the
region.
* liam having hard time following as can't see what is projected
* astearns liam: it's mainly bullet points that are actually being
captures in Dave's comments
* astearns liam: and examples that look very much like css-page-
template code
dauwhe: Footnotes still require an amount of magic. It has to be
on the same page and there's problem that the footnote can
be close to the bottom and need to flow.
dauwhe: I think this makes the underlying structure a bit clearer.
dauwhe: This might be a good way to solve running-head problems as
well.
dauwhe: Doing this with flows and this flow option static seems to
be a good way of doing that.
dauwhe: We could also define these margin boxes using the slot
idea or something similar so we could have arbitrary
numbers in arbitrary positions, which I know there has
been interest in.
* liam q+ to note that "on same page" applies also to
figures/figure references, and marginalia and may be worth
making non-magic
<SteveZ> I think that Rossen's suggestion that a footnote element
affect both the place where it occurs and also have
content that moves to a flow is a good one
<liam> +1
dauwhe: So that's what I'm thinking right now and I'm wondering if
it makes sense and if it's implementable and if this is a
better direction.
glazou: I think this is consistent with what I said the potential
for paged media 4 is. All the features I said were needed
are here. In my opinion I'd like to see that in a draft.
glazou: I think that both the web and the publishing industry need
it. We need it for dynamic web.
hober: I think this is good. I'm happy to see a resurrected @slot.
hober: You mentioned it's difficult to leave something behind, it
got me thinking.
hober: We have relative positioning that leaves a place holder.
fantasai: Absolute positioning.
hober: Relative is offset from where it would be in flow. There's
a place holder taking a space.
TabAtkins: Its geometry is still there.
dauwhe: So it knows where the top corner is?
hober: So suppose you wanted to put something where the place
holder is. If we have a pseudo for filling the area you
could use that for both cases.
hober: It's ::place-holder or static or whatever.
hober: You wouldn't have to define that yourself, we could do that
elsewhere.
dauwhe: If I had that I could throw things on there to add
numbering or side notes.
hober: So that's a question for astearns. With regions, you tell a
bunch of elements to flow and they get yanked out. Is there
a use-case for inserting content where it flowed from?
astearns: In this case, one of the original use cases for
named-flow is to take figures out where float position
isn't adequate.
hober: So like frame 1.
dauwhe: It's in huge use in academic needs.
glazou: It's a footnote reference.
dauwhe: This is huge in academic publishing.
astearns: And we could use it outside of this flow. Instead of
leaving entire geometry there the place holder gets...
hober: I'd leave relative position.
astearns: This is a new thing...
dbaron: One term thing is that we often use placeholder for the
thing in the original in absolute so use of placeholder in
relative is confusing.
glazou: The only complex thing is the magic for the link between
footnote reference and that's magic. Have you thought of
that?
dauwhe: No.
glazou: I have a solution. We can talk about it later.
astearns: You mentioned abandoned page...
astearns: I've been thinking as positioned we'd been waiting on
paginated view and then do page templates, but you're
concerned with printing.
<liam> [note that "on same page" applies also to figures/figure
references, and marginalia and may be worth making
non-magic]
glazou: I think we can do one without the other.
dauwhe: This is an improvement to GCPM. We can start to build out
pagination concepts in the environment.
<SteveZ> In an interactive environment, it is desirable that
footnotes turn into a call-out which if you mouse over
gives you a tool tip with the footnote contents.
<liam> [interactive env - disagree with stevez because ebooks
don't do hover very well - must be possible to have visible
footnote area]
fantasai: It seems we're in right direction, I think it needs more
work. I wouldn't say this is definitely it, but I like the
direction we're moving in.
fantasai: I noticed with @slot you had required-flow, and it made me
think about how the content property works.
fantasai: For pseudo-elements like ::before/after, if content has its
initial value, the pseudo is not generated. But if it has
content, it is generated.
fantasai: In the past, we had considered having flow-from use 'content',
that would behave as we want here.
glazou: In some books you need the area even if it's blank.
fantasai: You can do that with 'content' as well (set it to blank string).
dauwhe: Does it take all its children, or just the text?
TabAtkins: It can if you have mixed text and URL, you can mix.
dauwhe: Okay. I may have a deep structure I have to move.
fantasai: No reason we can't define content to do that.
dauwhe: My knowledge is based on implementations that give a
non-starter.
fantasai: So instead of flow-from you'd say content: flow-from()
fantasai: If we had done that, syntax for the behavior would
fall out.
astearns: In two properties it lets you decide if it's at original
value and you can get the situation you described.
dauwhe: I've done a lot of books with one teachers edition and one
student edition and there might be places where you have
teachers notes that needs space, but shouldn't appear for
students. So we have thing things occupy space without
showing.
dbaron: If they're the same size it's a good use for visibility:
hidden.
glazou: Also you can have annotations by students.
glazou: You may want them to fall into footnotes, not margin.
dauwhe: It does bring up that footnotes are annotations.
jet: So when you have the teachers edition, you have non-security
issues.
liam: I think that the link between margin area annotations
footnote and figures is they all have the constraint that
they're on the same page as the reference.
liam: So I don't think we should go too far from annotations.
liam: It's worth remembering for an ebook, the important thing
about footnotes is that you design a book so user can glance
at the page and see the notes. You don't need to do any
action.
liam: So in a book reader you want the footnotes area to be
possibly always visible.
liam: So you need the footnotes specially styled so it appears in
the right place.
liam: I can't see the examples, but you want to make sure the user
agent knows the footnotes are there in some way.
dauwhe: I agree the visual model has value that we haven't been
able to achieve digitally. Being visible without user
interaction but being discreet is something we don't get.
dauwhe: I'll write an email with the syntax when I get a chance.
dauwhe: So this feels like a good direction?
plinss: We want to make sure footnote isn't limited to @page
dauwhe: Yes.
plinss: You should be able to generate a box and put it somewhere.
dauwhe: It also...We might need special behaviors with
Korean-style side ends. That's another reason to use this
more generic syntax.
dauwhe: Okay.
glazou: What do you want from us?
dauwhe: The question is...given the history of GCPM, getting
something done is high on my list. One possible approach
is to do a minimal footnote implementation that matches AH
and Prince as level 3 and start this at level 4
* liam q+ to check that proposed approach does not preclude
multiple levels of footnotes in the future
hober: Is it possible to describe behavior with the same model at
the fuller level 4?
hober: This can be a simpler expression.
glazou: There's magic in the current GCPM. Overflow behavior of
footnote is badly defined.
glazou: It should be better.
dauwhe: Maybe I'll try and write this up and I would love some
assistance on what I exactly need to define further.
hober: It makes sense to write what we want and then write what we
need.
glazou: So you would prefer a requirements doc?
hober: No, it seems to make sense to flesh out level 4 and
backfill into 3
<SteveZ> +1 for hober's comment
* glazou agrees too entirely
fantasai: I agree. In some cases I wouldn't but in this case we
need to know where we're going.
dauwhe: I don't want to spec ourselves into a corner, though.
astearns: Liam has a question on the queue about not backing into
a corner.
<TabAtkins> liam: What do you mean by "multiple levels"?
<liam> [ https://www.w3.org/Style/XSL/Group/2008/06/footnote-examples/pages/Hearne-Itinerary-5-15/
is an example with 2 levels of footnotes ]
<liam> [ Member-only link, sorry - I could move it somewhere
public I suppose ]
<liam> [ multiple levels can also be considered multiple streams
of footnotes, e.g. in a multilingual doc with all the greek
together & then all the english notes ]
dauwhe: Syntactically we have it into @page and we could keep
going.
hober: Everything is a custom-ident there.
dauwhe: I could build another slot inside the slots.
glazou: So the draft you're proposing is integrating from page and
paged media 4? Is that needed for these documents?
glazou: Do you prefer keeping paged templates on one hand?
dauwhe: Initially keeping them separate because I don't know where
this will end up.
hober: Yeah.
astearns: I think it makes sense. To solve footnotes it may be you
want to solve it and then we see if we can extend.
hober: To ask the process question, is there charter concern with
this having possible overlap?
glazou: There's something...in short no.
astearns: There's one issue you mentioned in codebug where if
you're just taking named flow this flow into footnote is
creating a single named flow and this is pulling on a
page by page basis.
astearns: You want a kind of flow, maybe flow-into page (footnote).
dauwhe: Yeah. We may need something like that
hober: We have something like that so that it's only things that
appear on this one page.
plinss: Footnotes sometimes need to flow.
hober: You can always.
plinss: Almost always, but not always. If the footnotes pushes off
the page...
<SteveZ> I think to do footnotes you need the concept of one
region (the footnote area) eating into another region the
body text area
<liam> yes (region intruding)
dbaron: And if the footnote can't appear on the page at all it has
to be all on the same page.
dauwhe: Prince has something where if things get bad just run the
reference on a new page.
dauwhe: So process-wise, would this be an ED of GCPM 4? Can that
coexist with 3?
TabAtkins: Yeah. We can't have two levels at the same status, but
if the later one is lower it's fine.
TabAtkins: If you take the entire previous level and try and sync
the changes, I recommend that level 4 is just the
things you're changing.
dbaron: It sounds like his idea of figuring out what the feature
should be will somewhat contradict that process.
dauwhe: I can figure it out.
plinss: You can write level 4 as you want and backport.
<SteveZ> I suggest that you put an issue in level 3 that points to
what is happening in level 4
<glazou> For the record:
http://lists.w3.org/Archives/Public/www-style/2013Jan/0133.html
glazou: Are you looking for a co-editor? I volunteer.
glazou: The link I pasted above is my thoughts on a new approach.
<liam> [I will be happy to review drafts, make diagrams etc., of
course]
plinss: So we should do a resolution for GCPM 4.
glazou: I wanted to do that originally in paged media 4 and we did
a resolution on that.
plinss: Since we're talking about a level 4 we should record a
resolution.
dauwhe: And we can address the relationship in the future.
RESOLVED: ED for GCPM 4
dauwhe: Thank you.
plinss: Next was test results, but we don't have clilley
plinss: So CSS OM?
...
plinss: Okay...Scoping?
TabAtkins: We can talk about that.
CSS Scoping
===========
<TabAtkins> http://dev.w3.org/csswg/css-scoping/
TabAtkins: Scoping is the evolution of shadowDOM Styling that I started
earlier.
TabAtkins: This creates unification with shadowDOM and scoped
styles and cascade that we didn't have before.
TabAtkins: The big thing is to first review the new scoping stuff
because there were some issues.
TabAtkins: And then I believe we wanted final sign-off on
shadowDOM selectors.
TabAtkins: The scoping mechanism is the unifier of the things that
scope.
dbaron: Wait so...scoped, what is scoped cascade?
TabAtkins: The effect of scoping a rule on how ti cascades
dbaron: The scoped element on the style element?
TabAtkins: Yes.
dbaron: So the change is in cascade priorities?
@scope rule
-----------
fantasai: [Pulls up the document on the projector]
fantasai: So there's no intro, but scoped styles describes what
they are and talks about markup mechanisms (that we
don't define here, but give examples). Then we have
@scope which is the new thing.
fantasai: Then we have the issue.
TabAtkins: So this is the CSS syntax to do get scoped style
behavior inside a style sheet. It should be equivalent
to using <style scoped>.
TabAtkins: There was feedback saying that being able to put such
styles in-line would make people use scoping a lot and
might defeat various performance assumptions in the
implementations that people don't use this much.
plh: Have you considered @global?
TabAtkins: That's further down. For now we dropped @global to
figure it out later.
fantasai: There's an issue on if there's multiple @scope rules
tied to the same scoping root, do we cascade them by
specificity or make them equal?
Selecting Outside the Scoping Root
----------------------------------
TabAtkins: Next is a pointer to the :scope pseudo and a possible
replacement for the @global rule.
TabAtkins: This is defined similar to how :host-context() is for
shadowDOM.
TabAtkins: It doesn't address everything @global would do but it
does the main useful thing.
dbaron: The defaults is that the selectors don't go out of the
scope?
TabAtkins: Yes. The default for scope style sheets is that it is
scope-contained, i.e. all parts of the selector must
match within the scope. The other option is scope-filtered,
where only the results have the be contained within the
scope.
TabAtkins: querySelector uses scope-filtered by default.
fantasai: And that confuses a lot of authors.
TabAtkins: Other potentials...
fantasai: This needs syntax setting for us to figure out what's
reasonable for us to express matching. This is
functional to match.
glazou: So whatever is the choice that the presence would trigger
selecting outside the scope?
TabAtkins: Yes. :scope-context() technically matches an element
inside the scope inside, but evaluates its argument outside it.
It doesn't quite cause an outside trigger.
TabAtkins: Another possibility is the select is handled directly
which is a way to select outside.
TabAtkins: There would be various combinator ways to trigger it.
The pretense of this causes us to start outside the tree
fantasai: There's a problem with not being able to do nested pairing
of slashes. We'd have to go with the 1st or 4th possible
idea in section 2.2.2 (since they use brackets).
<dbaron> 1. :scope-context(<selector>) div
<dbaron> 2. scope(<selector>) div
<dbaron> 3. /scope <selector>/ div
<dbaron> 4. <selector> /scope/ div
glazou: I don't like the backslash, but I like the one character
determining non-scope selector and the scoped one.
glazou: Where did you add scope?
TabAtkins: The idea is the tie into the named combinator idea.
glazou: You can extend that. I'd prefer 3.
fantasai: Problem with that is the nesting.
TabAtkins: We couldn't do a /deep/ selector in that argument.
fantasai: If there's other ideas or opinions I'd like to hear them.
fantasai: Or any approach besides an @rule.
TabAtkins: On that note one thing this selector approach wouldn't
do is differentiate between names defined within a
scope vs global. It wouldn't be good to have a way to
denote.
glazou: Can you add an example?
TabAtkins: Yeah.
glazou: A real example.
ACTION TabAtkins fantasai Add an example to section 2.2.2
<trackbot> Created ACTION-625
Naming ShadowDOM selectors
--------------------------
fantasai: Next is shadowDOM stuff. This is basically the text. It
gives an example and an overview.
fantasai: There's the issue of whether browsers should do shadowDOM
at all, which is out of scope for today.
fantasai: But the next thing is the syntax of the various shadowDOM things.
TabAtkins: We ended up getting agreement on all our points so we
should be good now.
TabAtkins: The interesting part is...only if you care about
shadowDOM we can go over it, but it's what we've talked
about. We can do section 4.
fantasai: There's a couple issues in the spec for syntax, one is
::content which crosses a shadow boundary but it seems
it's just a pseudo for selecting the contents of an element.
fantasai: Unless you're using shadowDOM, it's not clear what it means.
It could use some bikeshedding so it's not too general.
hober: It says specific to the projected content, so why not
projected-content?
TabAtkins: It's a million, or 16, characters
fantasai: We can do ::projection?
dbaron: Are they exposed to authors?
TabAtkins: They are in shadowDOM.
astearns: Wasn't this ::distributed?
TabAtkins: About a year ago. That was also unclear.
fantasai: This one is more unclear.
fantasai: My best suggestion is to call it ::projected.
hober: It's better than ::content.
astearns: ::projected vs ::projection.
dbaron: I'm disturbed by the number of terms exposed to authors in
ShadowDOM.
dbaron: I think it's okay to have a lot of terms in the spec, but
you may want to be careful about exposing too many.
TabAtkins: I don't know the general policy. I may be using
technical terms and we might have less stupid terms for
general discussion.
fantasai: I don't think we do.
fantasai: I think this should be renamed.
fantasai: On the suggestion list we have ::projected and ::projection.
Anything else?
TabAtkins: Besides ::content, no
zcorpan: shadow-content?
TabAtkins: It's not actually shadow so you don't want to invoke
that word.
glazou: Projected and projection are both bad. I dislike them both.
hober: light-content?
TabAtkins: The naming scheme came from me making legend of Zelda
jokes when we were starting the project.
dbaron: Maybe that's why I find it confusing?
fantasai: You're taking the light DOM and then you have an element
with children that's a shadow host. Then you attach
a shadow tree. Inside the shadow tree you have an element
that says grab the light children of the host element
and arrange in this fashion.
fantasai: So it's not exactly the light content.
dbaron: So are you selecting based on the path through the
shadowDOM?
dbaron: There was something about a projection. Are you running
selectors on the tree that results?
TabAtkins: More or less. It is linked to the children. It selects
children of the shadow host and then selects against
the children in the shadow.
plinss: You can also select to the side.
dbaron: So the tree that results we used to call fully flattened.
TabAtkins: Depending on what you mean by fully flattened.
fantasai: If you go down another level of shadow you don't see
things.
dbaron: We don't need to do this now
TabAtkins: [draws it on the whiteboard]
TabAtkins: The ::content only selects what can be seen by the div
unless you explicitly descend into the shadowDOM.
TabAtkins: So it's not fully-flattened.
dbaron: So ::content is for styles in the shadow stuff.
TabAtkins: From the outside you could do ::shadow ::content div
and you can carve a path.
dbaron: So ::content gets you from the shadow to the light?
dbaron: And ::shadow the reverse?
TabAtkins: Yes.
TabAtkins: All the interesting examples have two or three levels
of shadows so it's interesting
fantasai: So I see three options for a name, content, projected,
or bikeshed
Rossen: Call it bikeshed.
hober: Wouldn't that get confused with the one we names bikeshed
years ago?
fantasai: That was renamed.
dbaron: I don't like light as a term, but was there a reason not
to do ::light?
TabAtkins: Yes. Because it goes to some of the light children, but
not all of them. The light is everything outside the
shadow, this isn't everything.
hober: We use content to mean everything too.
fantasai: [writes example on whiteboard]
fantasai: So what I'm looking at isn't the light DOM, but a
projection of it through the shadow tree. It could be
the same, but it could be something different.
fantasai: It could be in the same order or a different order, or
mangled in some way. It's filtered.
plinss: So if I have a regular selector, I could just say x-ul
even though it's been propagated through the shadow.
TabAtkins: Yes.
fantasai: So we have three proposals.
fantasai: 1) ::content 2) ::projected 3) ::shenanigans 4) ::light
plinss: So how firm are the terms for these concepts in the shadow
world?
TabAtkins: They've been stable for a while.
TabAtkins: Spec names have been stable.
plinss: We should align with what they use.
fantasai: I think we (the CSSWG) spend more time thinking about
the authors when we set names.
hober: If we come up with a good name, we should suggest they
change.
fantasai: I think we need to come up with something clearer.
astearns: I like ::projected-content
fantasai: 5) ::distributed
<dbaron> 1. ::content
<dbaron> 2. ::projected [-content]?
<dbaron> 3. ::shenanigans
<dbaron> 4. ::light [-content]?
<dbaron> 5. ::distributed [-content]?
TabAtkins: You can only style them if your style sheet is outside
of the component. If you are inside you don't have
access to the inside.
fantasai: The code that creates and shadow.
plinss: If I'm walking the tree am I still seeing these things?
TabAtkins: Not through ordinary DOM methods. If you use ::content you
can ask for where things were redistributed.
plinss: So if we have examples of using from outside, you won't do
that unless you have bizarre structure you shouldn't do.
TabAtkins: Right.
fantasai: Any other possible names?
plinss: Do you want a decision now?
fantasai: I think we need something better than ::content.
hober: So does anyone object to removing ::content from the list
of options?
TabAtkins: Yes.
hober: To changing it to something else?
TabAtkins: I don't know. I can tell you yea or nay once Dimitri
responds.
TabAtkins: I need to talk to people to know my opinion.
hober: So there's a potential objection to changing from TabAtkins.
Does anyone else object to changing?
hober: Who thinks we should change it?
[11 hands]
fantasai: Okay. So TabAtkins if we decide to change it...
TabAtkins: I'll object or not depending on if we think we can
change it.
hober: I thought part of the deal with early shipping is you have
to change if we decide to change.
fantasai: So we have one branch of TabAtkins objections and one
where he doesn't. Let's work on the branch where he
doesn't.
fantasai: So let's remove ::content.
hober: and ::shenangians
fantasai: Okay. Any objection?
[silence]
fantasai: Any other proposals to eliminate?
zcorpan: With or without -content?
plinss: If they all have the content option?
zcorpan: I would vote differently with or without -content.
TabAtkins: This isn't simple voting.
hober: We can do one poll with and one without.
dbaron: Or we do a poll where you can do state both preferences if
they vary.
astearns: I think my preference varies on if it's there.
zcorpan: If -content is there I prefer light, but without it it
doesn't make sense.
astearns: I had that exact thought. Light with content matches the
shadow pseudo and so it's explicable to authors that
requires that content suffix.
dbaron: Should we remove the ? from 4
dbaron: Does anyone think it should be ::light without the
-content?
hober: I can live with it, but I prefer it to have -content.
fantasai: Any other options?
<dbaron> now we have 4. ::light-content?
fantasai: Let's poll?
glazou: Abstain.
glazou: Because the whole thing seems to be crazy.
Rossen: 2
hober: 5
glenn: Abstain.
koji: Abstain.
jet: Abstain.
zcorpan: 4
astearns: 4
TabAtkins: 1 or 4
andrey: Abstain.
adenilson: 2 because when it comes to projection it matches the
concept of shadowDOM.
adenilson: I think it makes sense.
<adenilson> http://en.wikipedia.org/wiki/Graphical_projection
<adenilson> projected makes sense if you think of the Shadow DOM
as a 3rd axis in the 2D DOM.
bruno: 2 but without -content.
dwim: 2 with or without -content
plh: Abstain.
shans_: 4
shinyu: Abstain.
dauwhe: Abstain.
dbaron: 5 than 4 than 2
plinss: 2
fantasai: 2 or 4. No order.
* sgalineau is same as fantasai, fwiw
fantasai: ::projected because the definition of "project" (verb)
matches what we're doing here.
fantasai: ::light-content because "light" ties into the ::shadow
terminology and because "content" ties into the <content>
element, which is what's used to pull these elements into
the shadow tree.
fantasai: So it's either ::projected or ::light-content
plinss: Roughly same number of votes.
fantasai: I think we want author feedback.
TabAtkins: We went through all these names and ::content sounded
best to authors.
fantasai: So we're down to these sounding good.
hober: I think these are both big improvements.
fantasai: They have different advantages.
plinss: So I'd recommend you note them both as potentials and get
author feedback.
hober: When you set up this poll there was a possibility that
TabAtkins would object. Are you?
TabAtkins: No. I would just object to a bad name.
hober: Do you think either are bad?
TabAtkins: They're both bad.
fantasai: I think we need author feedback.
TabAtkins: I'll only object if we don't get author feedback.
fantasai: So we'll put them both in and create a poll.
hober: If ::content isn't an option, should we provisionally rename?
TabAtkins: I want to put ::content in the poll.
astearns: Some people in the WG object to ::content so putting it
in will make the poll stall.
TabAtkins: But what if authors want ::content?
plinss: People in this room are looking at all of CSS and we can't
make people do that in the poll.
hober: So can we agree to not have ::content?
astearns: I suggest we say we want to rename ::content to one of
these things. If author opinion is so strong you'll get
write in and you can bring it back.
<dauwhe> astearns: +1
hober: It is the case that if the option is on the poll it will
change minds.
plinss: We've had authors scream for things that we'll never do in
CSS.
TabAtkins: I've also had authors give us great ideas.
plinss: But we've already thought of ::content and rejected it.
dbaron: And the way you word a poll strongly influences the result.
TabAtkins: That's why I have fantasai read these polls.
ACTION TabAtkins poll on the author option for replacements to
::content
* trackbot is creating a new ACTION.
<trackbot> Created ACTION-626 - Poll on the author option for
replacements to ::content [on Tab Atkins Jr. - due 2014-
05-27].
Deep Descandant Combinator
--------------------------
fantasai: Next issue was about the deep combinator
fantasai: The /deep/ combinator is a super descendant and it goes
through whatever it needs to.
fantasai: TabAtkins suggested it would make sense that instead of
using /deep/ we should make it a triple child combinator.
astearns: I really like the triple combinator.
fantasai: I think it makes them all fit together.
dbaron: Is this with whitespace?
fantasai: Either
hober: Between the >> signs
fantasai: Oh, no.
TabAtkins: It's a triple glyph
plinss: Are these new tokens?
fantasai: Any other options?
plinss: I like it.
fantasai: Any negative opinions?
TabAtkins: I have less opinion
fantasai: Maybe raise hand if you like the triple?
TabAtkins: Only if we do the double.
hober: I'm not crazy about adding something redundant.
hober: It's aesthetically pleasing, but we shouldn't add author
exposed things for ascetic reasons.
TabAtkins: Sure we should.
hober: I won't object but I'm concerned.
TabAtkins: If a relative selector starts with a combinator explicitly
you're fine. Else wise you look for a :scope and if you
have one, then you resolve that way.
TabAtkins: Because the descendant combinator is white space,
it can't currently trigger the "starts witha combinator" case.
hober: So, that's a use case, so it's fine.
dbaron: I wonder if there's an analogy for peoples like/dislike of
== and ===== etc.
dbaron: I don't think the analogy is that strong so I think I'm
okay with it.
plinss: So no one is objecting?
TabAtkins: The double/triple.
<TabAtkins> Proposed resolution is add ">>" as an alias for the
descendant combinator, and change /deep/ to >>>
RESOLVED: Add ">>" as an alias for the descendant combinator, and
change /deep/ to >>>
fantasai: That's all the issues in the draft except things we need
to write. Should we go over anything else?
plinss: So that's it on scoping?
fantasai: The only thing we haven't gone over is :host.
fantasai: If we go with ::light-content maybe we should go with
something else?
TabAtkins: No, that's unrelated. This is the right name for the
author facing thing that's holding onto the shadow root.
Region/Fragment Styling Rules
-----------------------------
TabAtkins: So we should do the regions styling.
TabAtkins: Since this is similar to the other topics we pulled the
regions stuff into this.
TabAtkins: They're all basically the same thing. Take chunk of
something that doesn't correspond to markup and figure
out how to style.
TabAtkins: We don't know what to do, but we've took astearns' text
and made a modification to say what we want to do.
plinss: My only concern is advancing scope in sync.
TabAtkins: Yeah.
fantasai: We might end up doing scoping 1 as small bits.
astearns: There was an issue about getting the style information
in the OM and I thought I had something in the old draft.
TabAtkins: Yes and we removed it to put in the issue to say why it
wasn't good enough.
plinss: Okay. Let's take a break until 11:15
[Break = 15 minutes]
Received on Wednesday, 11 June 2014 13:00:55 UTC