W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-13 Part III: Fetch and CSS Interactions, EXI for CSS, Display Module [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 21:32:17 -0500
Message-ID: <CADhPm3sRonMefv6_XXZNJQaWYfjks7_6=MhbVZC-nRm=y83h2A@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Fetch and CSS Interactions
--------------------------

  - RESOLVED: Integrate with Fetch Integration

EXI for CSS
-----------

  - iank will write the formal CSS group response to the proposal.
  - Most felt that due to its constraints and similarity to GZIP
      there wasn't a need to invest more CSS WG time in EXI.

Display Module
--------------

  - RESOLVED: Root is in-flow.
  - RESOLVED: table-caption and table-cell are flow-root.
  - RESOLVED: Mark the two value at risk (in reference to
              'table-caption flow-root').
  - RESOLVED: display:contents behaves as display:inline for all
              replaced elements and all form controls
  - RESOLVED: only elements with boxes can affect counters (and
              elements with 'display: contents' aren't such)
  - RESOLVED: ::before and ::after still exist, clarify spec
  - RESOLVED: Keep <br> and <wbr> magic, but add an explainer about
              how to mimic the results.
  - There will be a note added to clarify the interaction of
      display:contents and event targeting.
  - The spec will clarify that run-in and ::first-letter will grab
      the first letter from the run-in.
  - RESOLVED: Punt display-or-not from the Display 3 draft.
  - RESOLVED: Publish a new WD of Display after the edits are done.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/seattle-2017

Scribe: fantasai

Fetch and CSS Interactions
==========================

  <nainar> https://lists.w3.org/Archives/Public/www-style/2016Sep/0103.html
  dbaron: One of the things Fetch spec does is to spec more about
          how network stuff happens.
  dbaron: Some of what this involves is having specs that describes
          when things are fetched from the network-
  dbaron: spec things in certain ways so that they provide relevant
          details
  dbaron: e.g. providing various destination types.
  dbaron: I'm not really on top of all this.
  dbaron: But the thing I wanted to point out is that Jonathan
          Kingston is trying to write a little spec for describing
          all the network fetches in CSS.
  dbaron: I would like to be encouraging to him, because this is a
          good thing.
  dbaron: I think it needs to be integrated into our specs, rather
          than standalone.
  dbaron: Although maybe standalone for a bit is good.
  dbaron: Wanted to point out that a) this thing exists.
  dbaron: And should we welcome it in.
  TabAtkins: Yes to both.

  astearns: Besides our resolving to integrate his work, anything
            else we can do to be encouraging? Reviewing?
  dbaron: I don't know if he wants it to be an ED in the group. I
          can ask.
  astearns: Anyone can help him work through issues?
  gregwhitworth: Anyone in the WG on the Fetch side of things in
                 WHATWG? zcorpan?
  TabAtkins: I would love to help Jonathan and Anne.
  TabAtkins: Anne won't directly contribute.
  gregwhitworth: Is Jonathan already a member of WG?
  dbaron: Not officially. I should probably ask him before summarily
          making him one? :)
  gregwhitworth: Worth asking.
  astearns: Anyone opposed to integrating this work?

  RESOLVED: Integrate with Fetch Integration

EXI for CSS
===========

  TabAtkins: The EXI group does a binary transliteration of XML
             dialects for XML purposes.
  TabAtkins: Proposed extending techniques to JSON and CSS.
  TabAtkins: They transcode CSS to XML and then apply XML
             compression to get a binary stream.
  TabAtkins: In order to get the compression that they talk about
             they do "perfect encodings".
  TabAtkins: This makes it fragile to changes.
  TabAtkins: Any changes we make to CSS, would have to review how it
             impacts binary encoding.
  TabAtkins: It also doesn't increase processing speed, is only for
             network transfer.
  TabAtkins: I'm also concerned that their performance numbers are
             comparing raw CSS and minified CSS to their transcoding
  TabAtkins: but doesn't compare with GZIP.
  TabAtkins: I suspect GZIP would be comparable to what they're
             doing, and GZIP doesn't restrict us in any way.
  <tantek> I'm going to offer TSS as an alternative, already
           implemented as open source: http://xent.com/tss.js (
           described in article
http://readwrite.com/2010/06/02/tweeting_in_color_from_the_annotations_hackfest/)

  Bert: They claim that GZIP has 2 disadvantages. Their method
        compresses better, and other is that for GZIP you need to
        uncompress.
  Bert: With their method don't need to uncompress, you just parse
        in.
  TabAtkins: We need all that memory anyway for the data structures.
  TabAtkins: We save a lot of the string text anyway.
  iank: That's not a lot of memory for a CSS style sheet.
  Bert: That assumes you're using DOM.
  Florian: If a non-browser implementation of CSS has stricter
           memory constraints...
  Bert: Not really meant for a browser, for very constrained impls
        of CSS.
  iank: In terms of the bandwidth side of thing, the fact that we
        have GZIP, other compression tech, we don't see that there's
        that much of a delta.
  iank: The negatives of it, we'd have to maintain 2 passes, every
        time we add a new property might limit us.
  iank: In terms of memory, we haven't seen the size that a style
        sheet takes be the problem.
  astearns: The solution isn't just CSS, it's "do everything in EXI"
  astearns: At that point would amount to something.
  <liam> [exi does better than gzip, especially on mobile devices]
  <liam> [there's exlso exploring gong on with JSOn and javaScript
         using EXI; EXI is also in use for the internet of things]

  iank: What we're more interested in is?
  iank: One thing people are asking for is, e.g. a table in JS
  iank: Big websites pass a lot of data in, want a jump table at the
        start.
  iank: To jump in and be able to parse functions very quickly.
  <liam> [jump table is in the requirements for next version of EXI,
         if that happens]
  iank: Want to push people to different web packaging formats.
  iank: One that the TAG and another WG are working on called Web
        Packaging Format or something.
  dauwhe: Packaging for the Web
  <smfr> https://www.w3.org/TR/web-packaging/
  iank: That concatenates a whole file over the network and then
        splits it out so that we can parse separately.
  iank: Nice caching behavior.
  iank: And also you get better compression perf over something like
        HTTP
  <dauwhe> see also https://github.com/dimich-g/webpackage/blob/master/README.md
  <iank> yup that's it.
  <dauwhe> iank we're interested in that packaging format for ebooks/
           docs/portable web publications

  TabAtkins: Conclusion is browsers in this room don't have need for
             solutions EXI provides.
  <liam> a little concerned that decision seems based on very
         imperfect understandings
  <liam> [exi for css did better than gzip in some tests, but more
         testing is certainly warranted]
  astearns: Can we action Ian to write a response?
  astearns: Cover a) comparison to GZIP b) additional constraints c)
            browser interest in other packaging solution
  astearns: Bert, is that a sufficient response?
  Bert: Offered to answer questions.
  astearns: Depends on their response, but seems unlikely to be
            necessary.
  astearns: It was great that they had blog post and presentation of
            all that information up front.

  ACTION iank Write a response to EXI for CSS

  <TabAtkins> FWIW, a quick and dirty gzipping of their
              (non-minified) examples shows gzip ~60% smaller than
              EXI results.
  <TabAtkins> For example, their boa.css is 120k natural, 35k EXI,
              but 15k zipped

Display Module
==============

Is the root element out of flow?
--------------------------------

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Aug/0332.html
  <jet> https://github.com/w3c/csswg-drafts/issues/743
  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Jul/0372.html
  fantasai: The first question is, is the root element out of flow?
  fantasai: We would like to say no.
  fantasai: We would like the root to be in-flow.
  fantasai: Is there any reason why it shouldn't be in-flow?
  tantek: Why was it defined as out-of-flow?
  TabAtkins: Because flows were defined to start at an out-of-flow,
             and the root was at the root of the tree.
  fantasai: Would prefer defining ICB as out-of-flow and root in its
            flow.
  TabAtkins: Yeah.

  RESOLVED: Root is in-flow.

  [fantasai explains issue in
https://lists.w3.org/Archives/Public/www-style/2015Jul/0372.html]
  fantasai: I don't have an opinion, it doesn't really matter.
  fremy: If it makes one more person happy, why not?
  TabAtkins: Only case it really matters is if you give two values
             and reparse out, would change that result.
  <TabAtkins> Specifically, if we say that table-cell is "flow",
              then if you write "display: table-cell flow;",
              computed value will serialize as "table-cell", while
              "table-cell flow-root" will serialize as "table-cell
              flow-root". (Or if we make opposite decision, get
              opposite result.)

  RESOLVED: table-caption and table-cell are flow-root.

  Scribe: myles

Should we compute 'table-caption flow' to 'table-caption flow-root'?
--------------------------------------------------------------------

  fantasai: On that note, should we compute 'table-caption flow' to
            'table-caption flow-root' or just say they're equivalent
            in behavior?
  fantasai: Both will behave the same, should one compute to the
            other or should we just say they behave the same?
  fantasai: Any opinions?
  ::silence::
  astearns: What is easiest?
  dbaron: Last I talked to gecko people, "we can just implement
          flow-root and ignore this to-value stuff b/c it doesn't do
          anything beyond flow-root"

  fantasai: We could just drop the second value.
  fantasai: Are there any two-value things we need?
  fremy: The only reason we need 2 is for display-outside;
         table-cell, display-inside: flex
  Florian: You don't want b/c tables are horrible, or do they just
           not make sense?
  fremy: You get that for free.
  Florian: Ignore me.
  TabAtkins: The important part about 2-mode is the alongside block
             and inline is the run-in value, and those can be
             combined reasonably with all the inner types.
  fremy: I thought the reason for the 2-value was to enable
         display-none: something.
  fantasai: We had 2 longhands and we dropped them for this level.
  fantasai: No one wanted to implement arbitrary combinations.
  fremy: Yep.

  astearns: You want to drop the value because we don't have the
            longhands?
  fantasai: We could drop the 2-value variants. This means you can't
            combine run-in .... we have inline-level things,
            block-level things, and run-in which are similar to
            inline but not always.
  TabAtkins: They are like inline but sometimes get wrapped in
             anonymous block.
  Florian: The reason we don't need them, is we already have
           keywords for the inline-* keywords.
  Florian: Wasn't that the way to not have to introduce the
           inline-variant of the next display type?
  all: Yes.

  Florian: What's the problem with the status quo?
  fantasai: Nothing.
  TabAtkins: Just some of the implementors don't think they need it.
  astearns: Except for this one case, they don't. Until we introduce
            something, or add a new layout-type.
  astearns: No strong opinions here.
  Florian: Weak opinion in favor of keeping it.
  fantasai: Anyone else?
  ::silence::

  astearns: Let's keep it since no implementors are rushing to
            remove.
  fantasai: We can mark at-risk.
  Florian: In the cases where the two are the same, should they
           alias each other? (flow and flow-root)
  ::silence::
  fantasai: What's easier to implement?
  gregwhitworth: I'm assuming not serialize.
  fantasai: They behave differently if you have block or inline, but
            not if you are a table caption or a table cell.
  Florian: Making them compute to each other buys us little, but
           making them do the same thing has nonzero cost, so let's
           not do it.

  RESOLVED: Mark the two value at risk.

Define interaction of display:contents and replaced elements
------------------------------------------------------------

  <fantasai> https://github.com/w3c/csswg-drafts/issues/540
  fantasai: If you say display: contents on a replaced element. What
            happens?
  Bert: The outer row of pixels gets removed?
  everyone: hahaha
  TabAtkins: Let's implement regions with this.
  tantek: If it's <object>, it has contents
  tantek: it has utility.
  tantek: With <img>, you could possibly display alt
  tantek: it is contents.
  TabAtkins: But alt isn't the contents.
  Florian: On form controls, it's more dubious.
  tantek: Form controls have value.
  Florian: That's behavior.
  tantek: Audio and video elements have contents, and you could use
          this to bypass what they were normally going to do.

  fantasai: We were going to define replaced elements like images
            and videos with the content property. Showing the
            element's DOM tree contents would fall out of that.
  fantasai: It seems useful.
  <tantek> alt is the contents of an img as demonstrated by what
           happens when you copy/paste across an img - you get its
           alt
  astearns: Some of these sound useful but others are dubious. This
            would be a big change form what's actually implemented
            where it does nothing on replaced elements.
  fantasai: It's a new feature though, so we could actually do it.
  fantasai: Also the feature isn't widely used.

  gregwhitworth: Please provide use cases.
  gregwhitworth: All our controls are completely different, so we
                 would have to do it one by one.
  fantasai: I wouldn't include the value, I would just include the
            content of the element.
  gregwhitworth: What's the purpose then?
  fantasai: The main uses: textarea, <object>, etc
  tantek: If it works on textarea, it should work on input.
  fantasai: But <input> doesn't have its contents as a child element.
  TabAtkins: It should just ignore contents or act like display:none.
  fantasai: We would act like the element isn't there.
  TabAtkins: But then the results are an accident from how we've
             designed these replaced elements.
  tantek: Designing by accident is bad design.

  astearns: Proposal: they should behave as display:none or be
            ignored.
  tantek: Counter: there are user-semantic contents b/c of
          copy&paste. You don't get nothing when you copy/paste
          images. You get the alt text.
  tantek: Therefore that is the contents form a user's perspective.
  astearns: But that is an attribute, not an element.
  Florian: tantek's proposal is a lot of work.
  tantek: We shouldn't use historical accidents to design this
          feature.
  tantek: It's already a bad design.
  Florian: Is there a simple way to spec what you are asking w/o
           going one-by-one?
  tantek: No.
  Florian: Lots of work is involved then.

  gregwhitworth: And what value would it provide?
  astearns: There are techniques for doing these use cases using
            script.
  tantek: "script" isn't a good argument.
  plinss: Saying that you can do this in script isn't a good
          argument.
  gregwhitworth: I want a super awesome use case if we are going to
                 say that we shouldn't do this in script.
  gregwhitworth: I disagree.
  Florian: Give alt for images, for form controls: nothing.
  Florian: Selection works differently for different form controls.
  astearns: I'd be happy if we could say "it does what copy/paste
            does" if copy/paste is specced.
  astearns: If someone magically had already done all the research
            and knows exactly what to do, how many implementations
            would do it?
  tantek: Actually, if you had do the research, it would be based on
          what browsers do today.
  tantek: Delegate to the editing TF.

  fremy: I object to anything else other than just block/none.

  gregwhitworth: What do you show for video?
  gregwhitworth: Do you just look at text nodes inside <video>?
  gregwhitworth: I have no desire.
  TabAtkins: There are no use cases here. Don't turn off form
             controls, don't do weird things with video.
  plinss: You may want to turn off videos or images.
  TabAtkins: But you don't have to do that in CSS.
  gregwhitworth: You can do it in script.
  TabAtkins: We don't do everything in CSS.
  TabAtkins: It does things it's good at
  TabAtkins: JS does everything else.
  TabAtkins: This is complicated and does bad things for some
             elements.
  TabAtkins: This is a bad definition so we should just do something
             simple for replaced elements.
  Florian: It does nothing on form controls, but something else on
           other things.
  TabAtkins: Then we have to say which elements do which behavior,
             we need a language hook, why is this so complicated?

  fantasai: Do we know which form controls are replaced elements?
  all: no
  fantasai: Then an arbitrary set of form controls will work one way,
            and others will work another way.
  Florian: What is a form control?
  Florian: We could say it does nothing on form controls regardless
           of if they are replaced element.
  astearns: It should either not apply (do anything) or take the
            wrapper off and show the element's contents, which will
            be broken.
  plinss: You might for <object>.
  astearns: But consistent behavior....
  plinss: It would motivate future designers of elements to design
          them better.
  astearns: I doubt it will have an influence on future design.
  plinss: It will have an influence on future design.

  fantasai: In terms of the future plan for the 'content' property
            applying to arbitrary elements
  fantasai: The idea there was that setting it to a URL would turn
            the element into a replaced element
  fantasai: Replacing its normal contents
  fantasai: Assigning that element 'display: contents' would make
            its box go away, and the 'content' property to be
            ignored, exposing its contents once again.
  fantasai: Which is consistent with the behavior astearns is
            proposing for 'display: contents' applied to replaced
            elements.
  astearns: I propose: display: contents act consistently on
            replaced and non-replaced elements displaying the stuff
            in the element.
  plinss: I agree.

  plinss: tantek's proposal is useful, we should create another
          mechanism to explain copy/paste
  plinss: then we can build up future things on top of that.
  astearns: We can do that after the editing TF explains how copy/
            paste works.
  tantek: We have elements in the presentation platform that will
          have magic, and that's in our queue to deal with.
  tantek: We don't what what a form control is or how it's supposed
          to be displayed.
  <TabAtkins> Note: while replaced elements have *markup* inside of
              them, that markup doesn't generate *boxes*.
  <TabAtkins> So the consistent answer is "basically display:none"
  TabAtkins: Video suppressed the display that happens naturally.

  dbaron: The fundamental question is that: display:contents should
          be "skip this box but insert the child boxes that you
          would have had" and some people say "you skip this box and
          instead you construct the boxes based on the child
          elements" which gives you a different box construction
          than children.
  plinss: Display is fundamentally displaying the box generation.
  fantasai: If you say "generate the box" it generates the box.
  fantasai: Video children don't get boxes because the video
            replaces them.
  fantasai: Let's say we describe the replacement mechanism through
            the replacement property. When you set a video's url,
            then the element becomes replaced. The contents are
            replaced. If it works the other way, you don't replace
            the child boxes.
  Florian: It shouldn't matter what the child is.
  Florian: display:contents is the same on a video and a div.

  TabAtkins: That is not a useful way to look at the problem.
  TabAtkins: This is astronomical engineering. We should do the
             useful thing here.
  dbaron: I'm with tab.
  dbaron: This would violate a bunch of specs, because they ignore
          things at the HTML level.
  dbaron: HTML or SVG say you ignore the children of an element.
  TabAtkins: Like <defs>
  <dbaron> https://www.w3.org/TR/SVG11/struct.html#SwitchElement
  fremy: What about <noscript>?
  fremy: You don't want to display the contents of a <noscript>
  rachelandrew: I can't think of anything you could ever want to do
                with this.
  astearns: suggestion: display:contents should display nothing for
            replaced elements.
  TabAtkins: I don't care if it's "nothing" or "display:none" but I
             do care it is one of those two.
  <tantek> it sounds like we are running into these problems because
           we are starting to wander into parser / DOM processing

  astearns: Any strong opinions?
  rachelandrew: display:none means it disappears, or you just get
                garbage? I guess I expect it to stay there.
  gregwhitworth: What about for teaching? Do you want to disappear
                 so it's clear what's happening.
  rachelandrew: If things disappear, the elements stay there.
  rachelandrew: With things like grid, people will use it.
  rachelandrew: Things shouldn't vanish.

  Florian: What does "no effect" mean? inline? block?
  TabAtkins: If we replace th "display" value, so we have to know
             what to replace it with.
  Florian: But then we become sensitive to whether the initial value
           is.
  fantasai: yaaaaaa we should make it disappear
  tantek: Another alternative is to document questions and not
          resolve.

  fantasai: Implementations are starting so we don't want to drag
            this out.
  tantek: This feature?
  astearns: undefined????
  fantasai: ... we could.
  tantek: What's the use case?
  gregwhitworth: :O
  fremy: This feature is shipping in firefox.
  gregwhitworth: Wasn't this designed to be a stopgap for subgrid?
  fantasai: That was one use case, I think.
  TabAtkins: It lets you drop containers that you needed for other
             reasons, that cause problems for layout.
  fremy: In Firefox it does nothing, the element is still there.
  astearns: We can't define that a particular property doesn't apply
            to a set of elements.
  fremy: In Firefox it ships and it does nothing.

  * jensimmons created this Grid example that requires `display:
               contents`: http://labs.jensimmons.com/examples/spacejam.html
  <gregwhitworth> jensimmons: I'm assuming as a subgrid stopgap
                  correct? That is the one valid use case that I'm
                  aware of, that said - I haven't been following
                  this one too closely
  <jensimmons> yes. If subgrid existed, I would have used it in this
               example. Although I have other examples where I would
               use display: contents over subgrid, even when both
               are available.
  <gregwhitworth> jensimmons: sounds good
  <jensimmons> gregwhitworth: if I could only have one, I’d pick
               subgrid. But if we have both, I can see using both
               for different situations.
  <jensimmons> gregwhitworth: beacuse of the mental model / ease of
               use
  * gregwhitworth wishes IRC had a like button like Microsoft Teams :/

  gregwhitworth: What's the computed style?
  <tantek> does it work on images? textarea?
  Florian: What if it was blocked in the cascade? what does "do
           nothing" mean?
  fantasai: If you put some text after the element, does it all go
            on one line? or what?
  dbaron: Many replaced elements ignore their display property.
  * fantasai doesn't believe that
  fantasai: If you say display:block on a form control?
  dbaron: They do block-ish things magically.
  dbaron: We aren't clear what a form control is.
  dbaron: There are some aspect of replaced elements which don't
          apply to form controls.
  <fremy> https://jsfiddle.net/x27jnhz2/

  fremy: We should just display:inline because we all agree what
         that means.
  fremy: It matches Firefox.
  astearns: Any objections?

  RESOLVED: display:contents behaves as display:inline for all
            replaced elements and all form controls

display:contents vs counter scopes
----------------------------------

  astearns: issue! display:contents vs counter scopes
  <astearns> https://github.com/w3c/csswg-drafts/issues/674
  TabAtkins: Does a display:contents element that has a
             counter-reset on it reset the counter?
  TabAtkins: Per lists, only things with boxes can affect counters.
  dbaron: That seems convenient.
  dbaron: If you have a nested list and you display:contents, you
          are asking for the list-items to participate in the
          numbering of the parent.
  dbaron: If you didn't want that, you should have set the margins
          to 0 instead.
  TabAtkins: [mentions a possibility where you might want a list to
             merge into a larger flexbox, and then that it's not
             important]

  astearns: Proposed resolution: have things happen as they do.
  TabAtkins: Make display specifically support what lists says.
  astearns: Any objections?

  RESOLVED: Only elements with boxes can affect counters (and
            elements with 'display: contents' aren't such)
  RESOLVED: ::before and ::after still exist, clarify spec

Display values for <br> and <wbr>
----------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/610
  TabAtkins: Display values for <br> and word break elements.
  TabAtkins: Original idea: these should be implemented in terms of
             content replacement with a string.
  TabAtkins: dbaron objected because string replacement is expensive.
  TabAtkins: We don't want to tie this feature to something that
             makes real pages more expensive.
  TabAtkins: We should have new values for a break and a word
             breaking opportunity, but it's not in a draft.

  <fantasai> Mats' response to this issue
https://lists.w3.org/Archives/Public/www-style/2016Mar/0379.html
  fantasai: Mats and BradK responded on the thread arguing that it
            should still be defined this way, and if an engine wants
            to optimize under the hood, then its okay.
  fantasai: This is a thing that is allowed in specs.
  fantasai: You could have a magic internal value which just gets
            serialized as "inline" and that's okay.
  fantasai: No one would be able to tell unless they looked at your
            UA stylesheet.
  <TabAtkins> nl { display: contents; } nl::before { content: "\a";
              white-space: pre; }
  <TabAtkins> ^^^ creates a fake <br> element named <nl>; works
              today in Firefox.
  <TabAtkins> ^^^ Swap out "\a" for a zwnj to get <wbr> behavior, I
              think.
  TabAtkins: You can implement <br> and <wbr> using things we
             already have and is implemented in Firefox but is
             expensive.
  fremy: But UAs can change this stuff.
  fantasai: Then you just opt out of your optimization.

  fantasai: It's a lot of work for tests and authors and spec
            authors.
  TabAtkins: Tests should happen anyway even if its not specced
             because the behavior is specced.
  TabAtkins: Putting it into a spec (the behavior) isn't a big deal.
  fantasai: It's adding to the set of CSS vocabulary.

  dbaron: What's the use case of authors customizing this stuff?
  TabAtkins: None.
  dbaron: Do we want to do this then at substantial cost?
  dbaron: If you want to do "it's this CSS thing and we explain it
          this way but you can optimize" then we have to write code
          for every <br> we need to check to see if the stars align,
          50 different checks, which may defeat the optimization in
          the first place.
  dbaron: We survived for 20 years with it being magic and we can
          survive another 20.
  fantasai: We should spec behavior, unspecified author's behavior
            potential changes
  fantasai: or like the UA stylesheet has !important and can't be
            change.
  astearns: What's the value?
  fantasai: Then authors know what it means and have expectations.

  TabAtkins: We could say <br> and <wbr> are magic, but you can
             reproduce with this: ______________
  fantasai: Yes. ::explains more::
  dbaron: That's fine.
  fremy: It's an okay idea.
  astearns: Resolve to spec magic?
  astearns: spec magic + "here's the trick: ______________________"
  <fantasai> We would use { all: reset !important; content: '\a'
             !important; white-space: pre !important; }
  <fantasai> Then the author can't change anything, but it's defined
             how it works.

  Florian: If you display:contents an element that has behavior like
           <a>
  Florian: is it still clickable?
  <dbaron> I believe the answer to Florian's question is yes.
  fremy: The trick doesn't solve if you have text-content on <br>,
         the text-content isn't rendered.
  fantasai: If you set content directly on the element, it overrides
            the DOM contents.

  RESOLVED: Keep <br> and <wbr> magic, but add an explainer about
            how to mimic the results.

  [Replying now to Florian's question: If you display:contents an
      element that has behavior like <a> is it still clickable?]
  dbaron: The clicking still works, the contents are still
          underlined and blue.... but wait maybe not.
  Florian: No underline is expected.
  dbaron: The clickable part happens in the dom, so it just happens.
  <dbaron> cursor change is from selector matching

  Florian: Are we sure we specced it that way?
  TabAtkins: We don't say what happens with the DOM
  dbaron: It should be clear: if event targeting to text that is the
          child of a display:contents element still targets an event
          at that element, not the parent of the element.
  gregwhitworth: How many people actually know that?
  TabAtkins: CSS doesn't affect event path re-targeting. That would
             be crazypants.
  astearns: Let's add a note.
  TabAtkins: Okay.
  astearns: Clarify the interaction of display:contents and event
            targeting.

run-ins: an alternative model
-----------------------------

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2012Aug/0257.html
  fantasai: ::explains the question::
  fantasai: It's less weird if the out-of-flows don't get rearranged.
  fantasai: Would be less weird if we don't shove the placeholders
            and put them into the subsequent box.
  fantasai: Currently if you have a run-in and there is a subsequent
            block box, the run-in becomes the child of that block
            box. if it doesn't exist, we wrap it in an anonymous box.
  fantasai: If you have two, they both run-in
  fantasai: (like heading & sub-heading)-
  fantasai: what happens if you have an abspos element between the
            two run-ins?
  fantasai: Do we decide that it doesn't run-in? or we run in the
            run-ins but leave the abspos behind? or put everything
            inside?

  dbaron: Does this also apply to floats?
  fantasai: Yes.
  astearns: run-in-y float position, where the float gets sucked
            into the next paragraph.
  Florian: [describes a webpage layout]
  fantasai: This is very obscure.
  fantasai: There are no implementations.
  fantasai: We just need a starting point.

  Rossen: For run-in.
  Rossen: We removed our support for run-in.
  fantasai: But we changed the model a lot.
  Rossen: Who wants to support this?
  fantasai: We have requests for it from the publication industry.
  fantasai: We should have a spec ready in case they succumb to the
            pressure.
  dauwhe: I will make hats for implementors if they implement.
  astearns: This should just be editor discretion!

  fantasai: No one has no opinion? Okay I will just say that we put
            the whole string of boxes into the next box.

Interaction between run-in and ::first-letter
---------------------------------------------

  <fantasai> https://github.com/w3c/csswg-drafts/issues/650
  fremy: There is nothing to discuss.
  tantek: We don't have interop.
  ::general objection to discussing this topic::
  Florian: ::paints a word picture::
  dbaron: Does the presence of first-letter suppress run-in.
  gregwhitworth: I like that option.
  Rossen: ::makes jokes::
  Florian: You have a heading H1 and a paragraph P, H1 is a run in
           followed by P, so it runs in.
  Florian: Which letter, if any, does ::first-letter select?
  Florian: h1::first-letter, p::first-letter
  Florian: Do we color the first letter of the H1? The first letter
           of the P? Neither? Both?
  <dbaron> We're discussing <h1 style="display: run-in">Heading</h1>
           <p>Lorem Ipsum</p>, in case that wasn't clear


  dauwhe: p::first-letter { color: green } should work
  dauwhe: I'm not thinking about the box trees and stuff, I just
          expect it to work.
  <melanierichards> +1
  dbaron: Selectors operate on the dom.
  astearns: That's what ::first-letter ::should:: do.
  tantek: Some implementations will colorize something after an
          image with ::first-letter.
  Florian: Don't we have a problem w/ initial-letter?
  gregwhitworth: Why would any author ever actually do this?

  Florian: What about saying ::first-letter doesn't apply
  Rossen: Does not apply?!
  tantek: Pretty sure that's what we said if there's an image.
  Florian: If that's who it works, we should do it here.
  gregwhitworth: and the spec says this?
  tantek: Yes.
  tantek: ::first-letter is under-specced
  <tantek> reminder, my "simple" test case with images and
           first-letters:
http://tantek.com/w3c/css/decorative-image-drop-cap.html

  <dbaron> What about the rule that initial-letter applies to an
           inline at the start of a block -- does that still work if
           something else runs in to the block?
  fantasai: The run-in is the first inline in the box
  fantasai: So yeah, no problem for it to apply if you're applying
            it to the run-in

  Florian: What is the question?
  Rossen: If you're not doing this with a selector, but with
          markup....
  Florian: At least its predictable.
  Rossen: And the run-in shifts it over.
  Rossen: Why would the initial-letter be the first letter?
  Florian: We could do that too, but we'd have to amend the
           definition of initial-letter
  Rossen: what does "amend" mean?
  Florian: ::quotes spec::
  Rossen: Let's move the conversation back to display: and run-in.

  Scribe: TabAtkins

  fantasai: ::first-letter doesn't apply to inlines, only blocks,
            right?
  dbaron: Yeah.
  fantasai: run-ins are inlines. So ::first-letter won't apply to
            them. (i.e. run-in::first-letter selects nothing)

  fantasai: For <p>, question is whether p::first-letter applies.
            I'm gonna say no.
  TabAtkins: That makes pseudo-element generation depend on
             properties.
  astearns: So if you have a headline and a paragraph, and the
            paragraph has a red first letter.
  astearns: If I change design, and run-in my heading, that doesn't
            change my decision.
  dauwhe: Why is restyling changing what happens to that paragraph?
  <fantasai> Quoting Florian: “p::first-letter should certainly not
             select 'L' and make it blue, as it is not "the first
             typographic letter unit on the first formatted line" or
             "The first letter of the first line of a block", and
             regardless of spec wording, it would be a bad idea for
             'L' to be selected here.”
  fantasai: So what do you do when you specify initial-letter on the
            L?
  tantek: This is why this doesn't work - it's not the typographic
          first character.
  dauwhe: Can we separate the initial letter and first letter
          problems?
  fantasai: Not really - we said initial-letter applies to
            ::first-letter. We can say it only works if it's the
            first formatted character...
  TabAtkins: So, first-letter depends on properties anyway, so
             objection withdrawn.

  fantasai: So proposed resolution is that none of the first letters
            exist.
  Bert: Why not the H?
  fantasai: Because those elements are inlines.
  Bert: p::first-letter could select H
  dauwhe: That seems surprising to me. We can say that the run-in
          kills the first-letter - the collision causes damage.
  dauwhe: But having it migrate seems weird.
  Bert: It's not migrating, it's just the first character in the <p>.
  tantek: Otherwise there's no way to style the first-letter.

  fantasai: Any objections to saying there's no ::first-letter?
  Bert: I disagree, but I want it on the H, not the L.
  dauwhe: I agree that it's not on the L. I could go either way on
          the H.

  astearns: Any objections to resolving that run-in into a paragraph
            means that no letters are selected as that paragraph's
            ::first-letter?
  astearns: I'm wondering if the definition of first-letter
            *already* selects the H.
  astearns: Is it the first inline in the block?
  jet: I think it is.
  astearns: So by making no spec change, we can select the H, and we
            might need to clarify the interaction, but disallowing
            the H means we need a spec change.
  astearns: So I recommend we *clarify* that run-in and
            ::first-letter will grab the first letter from the
            run-in (the H in the example).

Publication
-----------

  fantasai: So that was the last issue. Any objection to publishing
            a new WD after the edits?

  RESOLVED: Publish a new WD of Display after the edits are done.

display:none property
---------------------

  fantasai: Oh yeah, the display-or-not property (the display:none
            property). We think it needs more work, so we want to
            punt it.
  astearns: Is there a new level to punt it to?
  fantasai: There might be, if not, we can just start it, or start
            an issue list for level 4.

  RESOLVED: Punt display-or-not from the Display 3 draft.

  Bert: There used to be a "display: compact" value.
  fantasai: That was a CSS 2.0 value. Been dropped for a long time.
  astearns: Raise an issue if necessary. Moving on to next topic.
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
	<tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
		<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
		</td>
	</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 02:33:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 February 2017 02:33:51 UTC