[CSSWG] Minutes Telecon 2015-04-22

Pre-wrap and White Space Processing Followup
--------------------------------------------

  - Everyone was encouraged to read the email from Florian outlining
      the different implementations and possible solutions.
  - Discussion will continue on the mailing list and this will
      possibly become a F2F topic in May.

Which spec for column-span: <integer>
--------------------------------------

  - RESOLVED: New ED for the next level of multi-col
  - RESOLVED: Add just Florian as editor for the time being

Media Queries
-------------

  - The grammar for <media-condition> will be changed to avoid
      requiring looking ahead by an unbounded amount.
  - TabAtkins and Florian came up with the right behavior set for
      @media not (unsupported-media-feature) vs @media not
      (unsupported+syntax), but it's different from previous
      proposals, so they'll contribute their new idea to the mailing
      list for further discussion/objections before hopefully
      getting resolution next week.
  - TabAtkins and Florian came up with a proposal to address custom
      MQ before an @import and will write the proposal for the
      mailing list.

Font MIME Types
---------------

  - RESOLVED: Font MIME type registration is out-of-scope for CSSWG,
              FontsWG has a (partial) list, forwarding issue to them

Allow Extended Hebrew Counters
------------------------------

  - RESOLVED: Add that people may support larger Hebrew counters if
              they want
  - RESOLVED: Re-publish Counter Styles CR with the above addition

Ruby inlinize algorithm
-----------------------

  - The spec authors need more time to consider this question.

Addition of a ::flex-line pseudo-element
----------------------------------------

  - This addition might be good for a future level of flexbox, but
      not for the current level.

Naming issue for cursor: default
--------------------------------

  - Consensus was that renaming the global default was the least-bad
      option and the name bikeshedding will happen on the mailing
      list.

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

Present:
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Dave Cramer
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns
  Johannes Wilm
  Steve Zilles

Regrets:
  Rossen Atanassov
  Sanja Bonic
  Adenilson Cavalcanti
  Alex Critchfield
  Peter Linss
  Michael Miller
  Takayuki Tsukitani
  Ian Vollick
  Greg Whitworth

  Scribe: dael

  glazou: Let's start.
  glazou: First thing, anything to add to the agenda?
  Florian: I was saying I have a few more things, but since the
           agenda is full I can ping you to add them next week.
  glazou: If you want to be sure they're added, drop an e-mail to
          plinss and myself.

  zcorpan: Starting next week I will be away until mid-Aug.

Pre-wrap and White Space Processing Followup
============================================

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0386.html
  Florian: Here's the e-mail. We discussed this a while back, but I
           had one problem because some of what I had was only
           partly accurate.
  Florian: Starting again, we have an interop problem with
           white-space:pre-wrap. There are three behaviors out there
           and IE, Webkit/Blink, and Firefox all disagree.
  Florian: In some cases IE disagrees with itself and does different
           things in textarea vs regular elements.
  Florian: Overall if you combine the properties you can't really
           control how things work. I think that's unfortunate. The
           mail explored who does what. I think there are a few
           useful behaviors using these properties. It would be nice
           to be able to switch between those properties, but right
           now you can't do that with switching. We should aim for
           more interop.
  Florian: I'm not sure we can discuss on the phone call because I
           think we need to look at drawings. I'd like to encourage
           people to look on the ML and we can have a discussion
           here on the high level on if interop is a desirable thing.
  <fantasai> +1 to f2f
  <andrey-bloomberg> +1 for f2f
  glazou: It can serve as a reminder for everyone to look at the
          e-mail and have it at the F2F.

  tantek: Is this errata?
  fantasai: CSS3 Text errata and new properties
  Florian: I'm not sure it needs new properties. We can probably get
           there with existing properties to describe it, but there's
           currently a lot of ambiguity. There's also spec
           violations. If you combine undefined behavior, ambiguous
           spec prose, and spec violations you get all
           these behaviors.
  Florian: Last time there was feedback from MS and Apple saying
           they didn't want to change, but given that there is no
           interop I'm not happy with that. I'd like to hear from
           the rest of the group on if they want progress.
  <andrey-bloomberg> +1 for interop as well
  fantasai: I'm happy to work on it but if implementors don't want
            it they'll ignore it.
  Florian: I'm a bit uncomfortable with not wanting to change
           something that isn't interop. But if browser vendors
           don't want to change that's tricky.
  fantasai: Given that everyone is silent, we can work on it and
            people can object.

  <Bert> (Very good e-mail by florian, by still best to use a white
         board, I think... I don't like spaces that collapse to zero-
         width, b.t.w.)
  <dbaron> I think interop is useful; these issues don't seem like
           the top priority for authors, but making simple changes
           seems like it could be valuable.
  * ChrisL would like to know why the browsers are not interested in
           interop here

  Florian: So look on my mail, I think I've worked out what everyone
           does, and I've proposed alternatives on what we can do.
           I'd like feedback. I can do it on ML or bore everyone at
           the F2F.
  fantasai: I don't have time until then anyway.
  glazou: So we'll revisit when there's more input or the F2F.

Which spec for column-span: <integer>
=====================================

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0496.html
  fantasai: Do we have any implementors? Others than Presto?
  <ChrisL> do we have any *maintained* implementations?
  Florian: This seems useful to me. Does Bloomberg have an impl of
           this?
  andrey-bloomberg: I don't remember. Let me check.
  fantasai: I think it's great that Presto implements this, but we
            dropped it from multi-col and it ended in GCPM. If
            there's no interest in impl we should drop.
  <Bert> Prince applies column-span: number to floats, I think.
  Florian: Bloomberg has an implementation. It was in a spec, but
           dropped because the spec was re-purposed. It's
           unfortunate to drop when there's two impl, even if
           they're minor implementations.
  johanneswilm: This was in page floats. The only reason it was
                removed is there were many different definitions and
                this seemed unrelated to page floats.
  johanneswilm: So the discussion was if it should be in its own
                spec or if it should sit somewhere.

  Florian: I can start a multi-col level 4 while we wait for other
           things.
  fantasai: The logical place is multi-col. If this was minor
            feature impl by a few minor things...it's great to
            document but layout features take a lot of work. If
            there's interest in impl this going forward we should
            have this.
  Florian: Bloomberg has this and would like to contribute, but
           that's hard without a spec
  <andrey-bloomberg> just to clarify Bloomberg commits are going to
                     chromium and hopefully upstream
  fantasai: This goes in multi-col, but that needs a lot of work and
            so you're volunteering to take on a layout spec.
  Florian: I'm not volunteering to take on the whole spec. I can
           create a new level until someone is ready to take it on.
           I'd be fine with it going at the bottom of page floats.
  fantasai: If you want progress it needs to be in a multi-col spec
            and work on the interactions. If you want a place to
            copy it, there's a copy on TR. If no one is going to
            work on it we can get it out of the way. If you want to
            work on it you need to do it with all the layout
            interactions.
  Florian: I'm willing to work on it and the interaction with
           layout, but working on multi-col in the whole is more
           than I can take on. I can work on this feature, but not
           the entire module.
  fantasai: I don't have a problem with you trying, but I want you
            to keep in mind that it wouldn't fit together unless
            multi-col has more riggor.
  Florian: I'm happy to keep it somewhere else, but dropping from
           all specs is a bad signal.
  fantasai: I don't want it in page floats because it's not a page
            float. We drop it or put it in multi-col
  glazou: That makes sense.
  <SteveZ> +1 to fantasai's position
  <tantek> +1 fantasai
  Florian: Are we comfortable with starting a new level of multi-col
           and I put that there?
  <dauwhe> +1 to put in multicol 2
  <Bert> +1
  fantasai: Start an ED and put it there with an issue where the
            rest of multi-col has to go there.
  glazou: Is there agreement on that?
  <johanneswilm> +1
  glazou: Objections?

  RESOLVED: New ED for the next level of multi-col

  Florian: Should I add the level 1 editors to level 2?
  glazou: So editors. Florian you'll be an editor?
  Florian: I can be for that part, but not the whole spec. I'd like
           the previous editors to stick.
  fantasai: That was Hakon.
  Florian: I think we have a resolution to add Rossen as well.
  glazou: Since Rossen isn't here, I suggest you start with just
          yourself and we'll add new editors.
  Florian: I can respond to comments on multi-col on other topics,
           but I can't commit at lot of time.

  RESOLVED: Add just Florian as editor for the time being

Media Queries
=============

  glazou: There's 3 remaining issues for Media Queries.
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html
  Florian: Do we have TabAtkins?
  glazou: He's calling shortly.
  Florian: Let's wait for him.

  glazou: jdaggett are you on for your topic?

  glazou: dbaron you had an issue?
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0508.html
  dbaron: Didn't TabAtkins say he fixed it? I don't think it needs
          telecon time either way.
  <dbaron> yes, tab said he fixed it in
https://lists.w3.org/Archives/Public/www-style/2015Apr/0265.html
  <glazou> thanks dbaron

<media-condition> grammar requires unbounded look ahead
-------------------------------------------------------

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0419.html
  Florian: The first issue is this, raised by SimonSapin.
  Florian: The spec is phrased in a way that it requires unbounded
           look ahead. It can be expressed equivalently. Re-
           phrasing to make it so would be possible, but would make
           the spec hard to read.
  TabAtkins: I'm fine with rephrasing. We have the railroad diagrams
             to make it easier to read. I'm fine with getting the
             grammar to point to better impl.
  Florian: I was worried about the prose afterwards.
  SimonSapin: We did make a similar change to paged media spec of
              the same reason, but it's not clear if it's a
              requirement or a goal of CSS specs to not have look
              ahead or if that's just impl detail.
  TabAtkins: I think it is a strong goal. Given we did it with paged
             media, I'm fine with rephrasing it. It's fine.
  Florian: Let's give it a shot and if it gets horribly confusing we
           can back up.
  TabAtkins: Worst case I put a note with an alternative approach
             that doesn't have the unbounded look ahead.

@media not(unsupported-media-feature) vs
      @media not(unsupported+syntax)
--------------------------------------------

  Florian: Next is this:
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Mar/0514.html
  Florian: Currently the <general-enclosed> parts of MQ work the same
           as @support. That's prob a mistake because @support
           returns false when it can't parse, which is sensible,
           since something that cannot be parsed is certainly not
           supported. But that's a problem for MQ. Just because you
           can't parse something doesn't mean anything with regards
           to the environment. It should have the same error
           handling where it invalidates the entire MQ.
  SimonSapin: This matters because it adds a not operator that can
              be used anywhere in MQ.
  TabAtkins: [pondering noise]
  Florian: Were you trying to make sure why you disagree? Do you
           have a reason to think it might be better the other way?
  TabAtkins: I recall us discussing this specific case where you
             'not'ed a thing that was invalid and I don't recall the
             conclusion.
  Florian: Back when you could only 'not' the whole thing this
           wasn't as bad.
  TabAtkins: I think this was when we added the boolean logic.
  Florian: I don't recall that discussion, but I think MQ and
           @supports should be different here.
  TabAtkins: I'm provisionally okay with this. I'll find the old
             discussion and re-raise it if I find an issue.
  Florian: So should we resolve, or wait for you?
  TabAtkins: Resolve now. The argument is good. If I find a reason
             why it's this way I'll re-open.

  fantasai: There is a special case for media type where if you
            don't recognize the type you're not that type.
  Florian: Yeah, I'm not changing that. Just the enclosed part of
           the grammar.
  SimonSapin: What's is the change?
  TabAtkins: Change the error handling so general enclosed stays as
             it is, if it matching the entire thing it invalidated
             the entire thing.
  SimonSapin: Isn't that the same as others?
  Florian: It is. Currently though it works as @supports.
  SimonSapin: But changing the evaluation would be the same thing as
              removing entirely I think. Error handling where if you
              don't match the grammar it's false.
  TabAtkins: I think you're right.
  Florian: You're probably right.
  Florian: So let's just remove it.
  fantasai: So let's say you have an unknown thing and 'or' and a
            known thing that's right. You want it to be true.
  TabAtkins: Yes, I think so.
  fantasai: That should work. We shouldn't throw out the entire MQ.
  Florian: With not it's not.
  TabAtkins: General enclosed can falsify up to the nearest 'or'.
  Florian: I agree with TabAtkins and fantasai.
  TabAtkins: I believe that's what I was thinking of to look up. In
             that case let's talk about having general enclosed
             falsify to itself. A real syntax error with false the
             whole thing.
  <zcorpan> "A media query that does not match the grammar in the
             previous section must be replaced by not all during
             parsing." http://dev.w3.org/csswg/mediaqueries/#error-handling
  <SimonSapin> maybe or X = X; maybe and X = maybe; not maybe =
               maybe
  <dbaron> Which of these are incompatible changes to media
          queries?

  SimonSapin: What if we have a tri-state logic?
  TabAtkins: Yeah. There is a bottom value.
  dbaron: So MQ right now only have 'and'?
  TabAtkins: Correct.
  Florian: I think we got the right behavior, but since we hadn't
           considered this before the call, you or I should propose
           to the ML and resolve next week.
  TabAtkins: No resolution for now, we'll discuss, if there's no
             objections we're good.

Allow custom MQ before @import
------------------------------

  Florian: Next one is more involved.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Apr/0017.html
  Florian: TabAtkins do you want this one?
  Florian: It's if custom MQ can appear before @import and that
           whole thing.
  TabAtkins: The definition of custom MQ has no restrictions on
             where they're placed. Standard behavior. This means
             standard import rules do restrict them. It might make
             it difficult to make an import conditional on a custom
             MQ.
  TabAtkins: That should still work. Never mind.
  TabAtkins: You can have an import conditional on a custom MQ, but
             it might take time to start loading. There's the
             further question of how to handle loops, part where
             there's a custom MQ in a MQ block and they're referring
             to each other. You can't exclude from being inside MQ
             because at minimum a conditional import applies to this.
  TabAtkins: So, I believe the rules should be if a cycle is
             detected in MQ rules, if a custom MQ depends on one it
             contains then that MQ name gets tainted and all
             instances are invalid and undefined.
  TabAtkins: This is similar to the custom property loop handling.
             If you get a loop in custom property it kills it and
             you can't recover until the cascade is changed to
             remove the loop. That's true here.

  fantasai: What's the case for making these conditional on
            anything?
  TabAtkins: Being able to set up a set of variables on arbitrary MQ
             is good and setting up MQ based on that is good. Like
             on narrow screens the relevant values are foo and bar,
             but there are other relevant values on a bigger screen.
  Florian: Another thing you can do inside a conditional is custom
           @support.
  fantasai: Wait...okay...
  TabAtkins: Producing and arbitrary large condition and wrapping it
             as an easy MQ name.
  fantasai: oookay. (doubtfully)

  Florian: Another thing from the ML is that we may want for
           preloader reasons to restrict them to only the top of the
           style sheet. That's not entirely orthogonal. We can just
           say if they're nested they do nothing, but that's a fast
           way to preload.
  TabAtkins: Yoav, who did a lot of work on the preloader for Blink,
             where it is fine for finding import urls, no one
             implements viewport parsing in preloader and he thinks
             that's a bad idea. Custom MQ lie somewhere in the
             middle of those things for difficulty. It's harder than
             a URL. My alternate proposal is we define a new meta
             value for HTML that lets you define a custom MQ up
             there that can be accessed by preloaders. Ones in style
             sheets are not.
  Florian: So you keep the possibility of custom MQs.
  TabAtkins: Yeah, they're not valid for things that require
             preloaders. You can still do it, but it'll evaluate to
             false during the preloading stage.
  Florian: I'm comfortable with that. I suggest we try and resolve
           on allowing @import and @custom MQ in the same place.
  Florian: And we have when you have a loop in custom media you
           invalidate the entire thing.
  TabAtkins: I can poke the HTML group for that.
  Florian: Because we can do that we shouldn't block the rest.
  TabAtkins: Yeah.

  fantasai: I'm not 100% sold on all these things. Can we do a
            simpler set? You can do custom media rules, but if you
            do them they come before @import.
  Florian: You still need to define how loops work because you can
           define media attributes. Since we have do deal with it,
           I'm not comfortable cutting this off from authors.
  <tantek> this sounds like it needs more thought
  <tantek> f2f topic?

  glazou: We can't resolve on the call. This is complex.
  Florian: I think TabAtkins and I agree, so we'll make a complete
           proposal on the ML.
  Action Florian to write a proposal for the mailing list
  <trackbot> Created ACTION-681
  Action TabAtkins to write a proposal for the mailing list
  <trackbot> Created ACTION-682

Font MIME types
===============

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0027.html
  ChrisL: Anne is correct. We do this because when @fontface was
          first discussed we wanted a new top level media type.
          Others hated it and we gave up and had this hokey string
          instead. One one hand I'm concerned about font media types.
          However, fonts are supposed to be in the registration
          tree, but they're not and the web ignores this.
  ChrisL: The font group has put WOFF2 and has defined the whole
          tree as a new font-* which answers the question of where a
          definitive list should be.
  <ChrisL> http://www.w3.org/TR/WOFF2/#IMT

  <zcorpan> or use text/plain, text/html, application/octet-stream...
  <tantek> +1 for font/

  TabAtkins: She's not wanting all the changes in CSS, they just
             thought CSS was a place for a definition.
  ChrisL: Having it in CSS3 Fonts is a place, but I'm pointing out
          there is a spec where it is. I'm not convinced we need to
          register these things, but they've decided to do that.

  glazou: So Anne wanted to know where to put a list of font types.
          So I guess making that spec the answer is enough?
  ChrisL: Yes.
  glazou: Did you contribute to the thread?
  ChrisL: No, but I can.
  TabAtkins: Note the font-* types aren't sufficient for the request.
             The Google analysis has several not listed fonts with
             decent usage. Where is this going?
  <TabAtkins> Full list:
https://lists.w3.org/Archives/Public/www-style/2015Apr/0224.html
  ChrisL: It's a WOFF2 appendix.
  TabAtkins: It doesn't have application-* types.
  ChrisL: We can add that.
  TabAtkins: That's what I wanted to check.
  ChrisL: I just wanted to have discussion here.
  fantasai: So out of scope, forward to fonts working group
  ChrisL: Yep.

  RESOLVED: Font MIME type registration is out-of-scope for CSSWG,
            FontsWG has a (partial) list, forwarding issue to them

Allow Extended Hebrew Counters
===============================

  glazou: We have 10 minutes and 4 things on the agenda.
  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0117.html
  TabAtkins: Hebrew counts is easy. I'm fine adding that
             implementors can do larger Hebrew counters if they want
             to.
  <Florian> +1
  fantasai: I'm fine with that.
  glazou: So is there objections?
  <Bert> (no objection)

  RESOLVED: Add that people may support larger Hebrew counters if
            they want

  glazou: Do we have someone from LG on the call?

  fantasai: We need a resolution to re-publish counter styles CR for
            this.
  glazou: Okay, objections?
  <andrey-bloomberg> +1
  <Florian> +1
  <astearns> +1
  <dauwhe> +1
  <zcorpan> +1
  Bert: No objection.
  <tantek> +1

  RESOLVED: Re-publish Counter Styles CR with the above addition

  <fantasai> Tab, don't forget to add to blow away the changes list
             and replace it with the change above :)

Ruby inlinize algorithm
=======================

  TabAtkins: I was asking fantasai if she had comments. It's
             relevant to other cases.
  fantasai: I need to dig deeper into this.

Addition of a ::flex-line pseudo-element
========================================

  fantasai: We might want to consider it for a future level of
            flexbox.
  TabAtkins: I agree.
  fantasai: Definitely not adding it now.

  glazou: So that's what we can do without LG. Anything for the
          remaining minutes?
  Florian: I have more, but don't remember length.
  glazou: Okay. Anything else?

Naming issue for cursor: default
================================

  Florian: Just sent a mail where we have a naming collision about
           the default value.
  <tantek> yay. cursor: default; vs. *: default
  TabAtkins: When was that added to cursor?
  tantek: CSS2.
  TabAtkins: Okay.
  fantasai: And default was reserved in CSS2.
  TabAtkins: Yeah. Okay.
  fantasai: It's in the font section.
  <tantek> time to dig through CSS2 WDs :P

  Florian: I can think of 3 options. One is you can't use global
           default on cursor. That would be unfortunate. We can
           rename the global. Or we can create a horrible special
           value like 'default-I-mean-it' for the cursor property
  <ChrisL> I wouldn't worry about using values we haven't reserved
  TabAtkins: The default isn't arrow for historical reasons, right?
  Florian: Yeah, but it's too late to rename.
  Florian: So anyone have a better idea?
  glazou: I'm sure we're going to hate all the ideas.

  tantek: Least worst is cursor doesn't get the global default for
          now.
  <astearns> +1 to tantek's position
  Florian: What about later?
  tantek: You worry when there's demand.
  Florian: The default isn't supported by anyone now. If we rename
           now we don't have a problem later.
  glazou: And not putting a special case in the code.

  tantek: Sounds like research is needed about applying default to
          something else. For the global default name. We need to
          research the bikeshedding.
  TabAtkins: That's the least unattractive option. We need to see
             what's been used and what's free on the ML.
  tantek: Can bikeshed figure that out?
  TabAtkins: It doesn't know literally all the properties because
             some specs aren't in bikeshed.

  glazou: Who will do the research?
  TabAtkins: Let's suggest things on the ML. Research is pretty easy.
  Florian: One down side is that default has been reserved for
           authors as well, but nothing else has so we may conflict
           with author names.
  TabAtkins: It's generally unlikely. There's only a few places
             authors can use custom names so I don't think we'll
             infringe.
  Florian: Let's try that on the ML
  glazou: Let's move it to the ML.

  glazou: Thank you very much and talk to you next week.

  <Bert> (Maybe replace by two values: user and ua, to reset to user
         style and UA style resp.)
  <TabAtkins> Bert: 'default' currently resets to the user level
              when used in author sheets, and to the UA level when
              used in user sheets.
  <TabAtkins> Bert: I don't think there's any reason to let the
              author explicitly reset down to UA, skipping the user
              styles.
  <Bert> That's my intuition, too, but I'm just brainstorming...
  <tantek> What TabAtkins and Bert said.
  <tantek> in addition, *allowing* the author to skip user styles
           goes against our design principles
  <zcorpan> 'ua-default' (with same semantics as now; people don't
            know or care about user styles)

  * fantasai is now wondering if we need to rename 'default' to
             'unset' and 'unset' to 'reset'
  <SimonSapin> fantasai, isn’t unset shipping?
  <fantasai> SimonSapin: probably. And probably the people using it
             don't know the difference :)
  <TabAtkins> Yeah, and "unset" still works fine for its current
              name - it unsets *everything*.
  <TabAtkins> But yeah, I'll bet some people using "unset" are
              expecting it to give UA defaults. ^_^

Received on Thursday, 23 April 2015 15:36:19 UTC