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

[CSSWG] Minutes Seoul F2F 2014-05-20 Part I: Footnotes in GCPM, CSS Scoping

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Jun 2014 09:00:26 -0400
Message-ID: <CADhPm3txnJhF1wFqmfSCtera4PsAzz6_78H=KCqtc9=y1ZG47A@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 June 2014 13:00:56 UTC