- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 21:32:17 -0500
- 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