W3C home > Mailing lists > Public > www-style@w3.org > September 2015

[CSSWG] Minutes Telecon 2015-09-16 [css-2015] [css-writing-modes] [css-text] [CSS22]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 17 Sep 2015 07:06:13 -0400
Message-ID: <CADhPm3s66T2JeNNJb59J5pbGy0+DSC7QMibPn8gTJ5j+i65T-A@mail.gmail.com>
To: www-style@w3.org
TPAC & Associated Events
------------------------

  - Everyone was requested to add items to the TPAC agenda so that
      scheduling can be handled in advance.
  - Anyone planning on attending the Japanese Industry Meet-Up on
      the Sunday before TPAC was asked to please add their name to
      the wiki as well as any topics they'd like discussed. The
      start time and agenda will be announced shortly after a venue
      is decided upon.
  - Lastly, anyone looking to attend the Monday evening developer
      meet-up at TPAC was reminded to sign up.

Prefixing Policy in Snapshot
----------------------------

  - Apple and Microsoft are still reviewing so the language couldn't
      be finalized.
  - Apple had some preliminary feedback that lead to further
      conversation about the word 'unstable' in section 3.2.3.
      Market Pressure and De Facto Standards.
      - fantasai will further clarify the word 'unstable' and
          perhaps use an alternate word.
  - The feedback also lead to a conversation about doing a better
      job making the case as to why the prefix policy change is good
      for implementors.
      - Florian will write up a note with the rational which he
          summarized in the call by saying: "vendors can remove the
          prefixed version once the bugs are ironed out because
          there will be no risk to compat by removing the prefix
          because everyone also used the unprefixed version."

Writing Mode Issues
-------------------

  - RESOLVED: Replaced sizing remains physical. Add an appendix
              about the consideration of the security and privacy
              concerns.
  - The authors plan to ask for a new CR publication as soon as next
      week so if there are any outstanding issues, please add them now.

Definition of White Space
-------------------------

  - RESOLVED: Add the form feed character (U+000C) and make sure all
              CSS specs align on the definition of white space.

Using Prefixed Examples in Specs
--------------------------------

  - The group agreed that they wanted cases like Florian's to be
      able to use a prefixed property in a spec example for what
      behavior should look like when implemented however the ability
      to do this is a W3C level decision so plh will discuss it with
      the appropriate parties.

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

Present:
  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Greg Davis
  Elika Etemad
  Simon Fraser
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Toru Kawakubo
  Brad Kemper
  Philippe Le Hégaret
  Michael Miller
  Edward O'Connor
  Matt Rakow
  Florian Rivoal
  Hiroshi Sakakibara
  Alan Stearns
  Greg Whitworth

Regrets:
  David Baron
  Daniel Glazman
  Tony Graham
  Peter Linss
  Anton Prowse
  Lea Verou
  Johannes Wilm

  scribe: dael

  astearns: We might as well start
  astearns: Any extra agenda items?
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
  Florian: If we have time we might want to look into this e-mail
           above. Tantek and I responded about allowing resize to
           apply to replaced elements.
  astearns: We'll put that at the end.

TPAC & Associated Events
------------------------

  <fantasai> https://wiki.csswg.org/planning/tpac-2015
  astearns: We need agenda items for TPAC so please go to the wiki
            and add things you want to discuss. The sooner we items
            on the sooner we get a schedule so we don't have to
            spend F2F time scheduling
  <fantasai> If no items, we will do a dramatic reading of CSS Box
             Alignment
  <fantasai> So add items
  <fantasai> :p

  <astearns> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0168.html
            [Member Only Link]
  astearns: Also, just reminding everybody about the Japanese
            Industry meet-up. Please add your name to the wiki
            saying you're going.
  skk: I'm trying to decide the venue. Then I will note that to the
       mailing list.
  skk: After that I will send a planned agenda. Please let me know
       if you have any questions or topics. I will send the agenda
       list within the week.
  astearns: Bert wanted to ask if the start time is known already.
  Florian: I think it depends on the venue, but the proposal was 3pm-
           7pm followed by dinner.
  astearns: E-mail says 3pm-4pm start and that will depend on where
            we end up meeting. I'll add a section to the TPAC page
            for industry meet-up questions and skk can reference
            that.

  Rossen: Since we're talking TPAC logistics, is it a good time to
          talk Houdini?
  astearns: I wanted to get through the rest of the agenda because I
            feel the Houdini conversation could take a while.

  <astearns> http://www.w3.org/2015/10/meetup-sapporo.html
  astearns: Other reminder is there's a Monday night meet-up. If
            you're interested, please sign up.
  Rossen: Which?
  astearns: W3C developer meet-up at Sapporo convention center.
  astearns: You can sign up for just the industry demos or also the
            social time afterwards.
  astearns: That's all for reminders.

Prefixing Policy in Snapshot
----------------------------

  <astearns> https://drafts.csswg.org/css-2015/#responsible
  Florian: There was something from Microsoft which was addressed. I
           think we're waiting on Apple.
  hober: I'm gathering feedback. Overall it looks good and is an
         improvement. Two areas of concern, though this isn't final
         feedback, both are around the difference between what we do
         and the new policy. First, when you ship a feature prefixed
         you should simultaneously ship unprefixed, that might
         change syntax. But that might be a big deal.
  Rossen: Is this a must?
  hober: Should.
  Florian: You must ship unprefixed, you should ship prefixed.
  hober: Yeah. That's something we're still talking about.
  Florian: I misspoke. The wording is should for both prefixed and
           unprefixed.

  * tantek notes the prefix discussion sounds confusing
  * tantek and if people are still confused remembering it, it
           probably needs rewriting to simplify the prose.

  hober: The second is the...let me pull up the draft...
  hober: The second bit is in market pressure and defacto standards
         [reads]
         Spec Text:
           If a feature is unstable, yet:
             - at least three UAs implement the feature (or a UA has
                 broken the other rules and shipped for broad use an
                 unstable or otherwise non-standard feature in a
                 production release),
             - and the implementations have rough interoperability,
             - and the CSS Working Group has recorded consensus that
                 this feature should exist and be released,
           implementers may ship that feature unprefixed in broad-
           release builds. Rough interoperability is satisfied by a
           subjective judgment that even though there may be
           differences, the implementations are sufficiently similar
           to be used in production websites for a substantial
           number of use cases.
  hober: The main concern is historically adding support for
         unprefixed and removing for prefixed are treated as
         separate engineering decisions. One is based on stability
         and one is on compatibility.
  <tantek> huh? unstable = ship unprefixed?!?
  <tantek> wow this is confusing

  Florian: To put some feedback on that in case the wording isn't
           clear, the intent would be is when you ship something
           unstable you ship it unprefixed and preferably ship it
           prefixed. The preference is that the authors would use
           unprefixed unless there's a bug. That changes the model.
           In the majority of cases the prefix would only be used to
           work around bugs and when you remove the bugs it would
           remove the compat hit.
  Rossen: I don't quite agree. The prefixed version in a majority of
          cases is to wait for other implementations to catch up and
          for specs to mature.
  Florian: Today, yes, that is the model. The way this is proposed
           for the future there is no reason to use prefixed when
           they're released simultaneously unless you're trying to
           be implementation specific.

  astearns: We're talking about an unstable property-that means it's
            implemented in at least 3 UA and there's rough
            interoperability and the CSS has consensus it should
            exist. That's a different stable.
  Florian: You may disagree with what's going on, but I wanted to
           clarify what's going on. If it's clear and you disagree
           that's a different discussion.
  hober: Personally I'm fine with it. It's 'should' which is like
         must unless you have a good reason.

  smfr: The spec needs a word for unstable but follows the three
        interop implementations.
  fantasai: It uses it for a spec that is unstable. So the spec is
            unstable but we have these things happening. We only
            have rough interop. The spec is out of date or
            incomplete or there's a ton of open issues, but we have
            all these people shipping. There will be problems
            because the spec isn't finished. This is like the
            transforms and transitions case where stuff was still
            changing and people were still implementing and there
            were all these issues.
  fantasai: We do need to be a bit more clear, but there's this
            stage where the spec is moving to stable and there are a
            bunch more implementations, but the spec isn't finished
            yet and might change.
  Florian: We shouldn't use a word that means unstable and matches
           all those criteria above. Because if you ship something
           that doesn't match the criteria you should still take
           this approach.

  tantek: A couple of points. I think the first problem is in our
          conversation of what means unstable vs interoperable. If
          we're using unstable we should use what an author would
          consider unstable instead of a spec implementation
          definition. If something works across most places authors
          will ignore that the WG thinks that it's unstable. I think
          that needs to get re-assessed.
  tantek: I understand the intention that changing the meaning of
          when you ship prefixed vs unprefixed is a good intention,
          but transitioning to that model will be so confusing and I
          think authors will just say screw it and use both. If the
          goal is to try and get out of this problematic situation I
          don't think that approach will work.
  tantek: I don't have an alternative to suggest.
  tantek: So first point, use of unstable needs to be author centric
          definition. Second is changing the meaning of prefixed and
          unprefixed is good intention but will fail.

  Florian: To your second point, I wouldn't be surprised people will
           be confused and use both, but I don't think it will cause
           problems. If people use both the unprefixed is in the
           style sheet so vendors can remove the prefixed. So I
           think it will be misused, but I don't think that's
           causing problems.
  tantek: Not causing problems isn't a high enough bar. If you say
          this path will improve the situation that's good.
  Florian: I think that when this is misused it isn't going to be a
           problem.
  tantek: So how about not preventing improvement?
  Florian: How does this prevent improvement?
  tantek: I'm trying to encourage you to re-word your argument in a
          stronger way. It sounds like you are close to
          demonstrating that the misuse won't prevent the
          improvement and in that case it's reasonable to move
          forward.
  Florian: I think it won't prevent the improvement where vendors
           can remove the prefixed version once the bugs are ironed
           out because there will be no risk to compat by removing
           the prefix because everyone also used the unprefixed
           version
  tantek: I think you need to put that into the spec. What if
          authors use both? And then put what you said. And that
          will demo why impl should use this new policy. I think
          that's a strong argument and it should be clear.

  tantek: Does that make sense to everyone else?
  * fantasai is in favor of clarifying :)
  astearns: I think some of the argument is in the section, but it
            can be improved. So I'm hearing we need to clarify what
            we mean by unstable and clarify why this change in
            prefixing policy is a good thing. So we can get that and
            circle around.
  <bradk> Are authors supposed to list the prefixed versions of
          properties last?

  ACTION Florian to improve the note explaining why the prefixing
         policy change is good
  <trackbot> Created ACTION-722
  ACTION fantasai fix up the terminology around 'unstable'
  <trackbot> Created ACTION-723

  tantek: I'd ask leaverou what she thinks unstable means when
          authoring.
  <bradk> "Unstable" = not ready for general use, features/syntax
          might change.

  astearns: hober, you're still collecting feedback. Do you know
            when you'll be done?
  hober: Not offhand.
  Rossen: We're still collecting too so I'm sure this won't be the
          last time we discuss it. Ideally the changes we're
          discussing will come about soon so we don't have to go
          back for another few weeks to circle back on this set of
          changes. It would be helpful to start stabilizing the
          subject.
  Florian: Yes. This is a change in terminology and a note. This
           isn't changing the actual policy.
  Rossen: They are still changes.
  Florian: I'll get to it soon.

Writing Mode Issues
-------------------

  fantasai: Koji sent a couple in. Let me pull up the DoC.
  astearns: The links I sent in the agenda were Koji's.
  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0100.html
  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Sep/0101.html

  <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-47
  fantasai: First issue don't need WG input, I think. For some
            implementations that need to support old writing modes
            values in SVG syntax but not CSS they could map over
            using UA style rule. I was going to add an example.

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0061.html
  <koji> this one:
https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0195.html
         [member only link]
  fantasai: Main one that's open is this one [#48]. Orientation of
            an <iframe> which is 300x150.
  fantasai: Does that orientation rotate in vertical text or do we
            keep it as 300x150? I lean to keep it because the main
            use case is plug-ins where they can't adapt. If there's
            a reason it should go the other way let me know.
  Rossen: I would argue the opposite. You can argue keeping the
          <iframe> and images default sizing logical...
  Rossen: Images are upright regardless. You're right.
  fantasai: We think the kinds of things that would rely on this
            default are more likely to be image-like the logic was
            lets make it stay upright.
  koji: Firefox, Webkit, Blink, and Trident by default do physical.
  Rossen: That's what we do. Everyone defaults to keeping the
          'default' size of <iframe> physical. So the width is 300
          and height is 150.

  Florian: Isn't there a security consideration?
  Rossen: What would be different than an image with a default size?
  Florian: From an <iframe> not being supposed to know what's going
           on. Well, maybe not really. Just ignore me, I'm not sure.

  fantasai: I think that's kind of it for things we need to ask the
            WG for help on. I'm going to go over the DoC and make
            sure everything is wrapped up and colorized. If there's
            anything you feel needs to be addressed in this draft
            that hasn't yet, please let us know. We're trying to go
            for CR soon.
  astearns: Do you need a resolution?
  fantasai: Yeah.
  Rossen: It's good to have in the spec that default replaced size
          remains physical.

  tantek: How about answering the security questionnaire?
  <Florian> https://drafts.csswg.org/css-ui/#security-privacy-considerations
  <plh> --> https://w3ctag.github.io/security-questionnaire/
        Self-Review Questionnaire: Security and Privacy
  tantek: I think you must include this section in the spec to go to
          CR if you're touching <iframe>. It doesn't take long and
          it's a good practice.
  Florian: Even if you end up saying everything is safe at least
           you've thought about it.
  tantek: Yeah, but even if <iframe> is giving a default size it's
          possible to leak information. If I can <iframe> youtube
          and get a default size and it's different if you're logged
          in that's not information I should have. You see what I'm
          getting at?
  Rossen: I don't. What you'll see from the <iframe> is if it
          defaults to 300x150 it will regardless of the writing mode.
          We're not changing anything about replaced default sizing.
          We're making it less detectable. Replaced sizing remains
          physical.
  Florian: That we go that way makes it safe.
  tantek: And because it's something potentially cross-origin it
          makes sense to put the survey answers in.

  fantasai: Because the answers are all no I'm not sure how it helps.
  tantek: It shows you've gone through and taken the time. There's a
          question about cross-origin.
  fantasai: But writing mode doesn't do cross-origin.
  astearns: I'm not that enthused about boilerplate no to every
            question, but I like that we thought about these things
            being there. Should we say in an appendix we looked at
            this and it was all no.
  <fantasai> +1 to astearns
  tantek: And maybe add a note about <iframes> being okay because
          it's the default size.
  astearns: So resolve to put in an appendix and say that we
            considered it as one of the reasons we didn't change the
            default replaced size.

  fantasai: Is there an official link to the questionnaire?
  tantek: The one from plh. I'm pinging the TAG every few weeks to
          publish a W3C note version on TR, but that hasn't happened
          yet.
  plh: The TAG is meeting. I can nag them for you.
  tantek: Please do.
  tantek: Last time I asked plinss was apparently assigned to
          publish it.
  <bkardell> tantek: didn't you mention this in tag meeting irc
             yesterday?
  tantek: bkardell, yes.

  RESOLVED: Replaced sizing remains physical. Add an appendix about
            the consideration of the security and privacy concerns.

  astearns: Anything else?
  fantasai: I think that's it for now. We should republish CR
            perhaps next week.
  plh: In terms of publishing you'll need to ping me or Bert.

Definition of White Space
-------------------------

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Aug/0237.html
  fantasai: dbaron sent this issue about making sure the definition
            of white space is synchronized across specs.
  fantasai: CSS 2 spec has two definitions depending on syntactic or
            white space that gets collapsed. One include the form
            feed character and one doesn't is the main difference.
  fantasai: We should align our specs and HTML and go with the list
            that includes form feed. It seems to be an error in CSS
            spec that form feeds weren't included since every other
            spec has it.
  fantasai: Certain browsers collapse other characters, but Firefox
            doesn't and they're not in any spec, so I think we
            should align on the historical.
  TabAtkins: I strongly agree. This is to deal with the white space
             used in formatting in your source code, so it should
             just be the handful HTML defines.
  astearns: Objections?

  * bradk would love to be able to collapse NBSP
  <bradk> NBSP in the HTML is almost always non-semantic
  <TabAtkins> bradk: It's usually used for alignment, yeah, not
              semantic purpose, but it's definitely not used in
              source code.
  * Florian is not sure how often people use form feed to format
            their source code...
  <TabAtkins> Florian: Right, it's not really used, it's just that
              matching definitions across specs is useful.
  <Florian> TabAtkins: sure

  fantasai: This would effect CSS2.1 errata and CSS text.
  tantek: Has there been testing on this?
  fantasai: dbaron had one in his message. Firefox follows the spec
            except the odd inconsistency on collapsible white space.
            Other browsers do this and more.
  tantek: So other implementations collapse the form feed. We have
          interop on that except Firefox?
  fantasai: Firefox includes form feed character. The CSS spec
            doesn't include that.
  tantek: Awesome.
  TabAtkins: It doesn't include it in the definition of white space
             in this one place.
  <tantek> +1
  tantek: Sounds good.

  RESOLVED: Add the form feed character (U+000C) and make sure all
            CSS specs align on the definition of white space.

Implementability of Computed Value Rules for align/justify-self/items
---------------------------------------------------------------------

  TabAtkins: I'm generally okay with the changes. I want to review
             and discuss with fantasai.
  astearns: Feel free to respond on the list.
  TabAtkins: Yep. It's in my 'need to deal with soon' folder

  astearns Florian, do you want to do your resizing topic next?
  Florian: Either that topic or the discussion from the member only
           list about using prefixed examples in the spec

Using Prefixed Examples in Specs
--------------------------------

  Florian: When doing a live example in a spec showing how a
           property would work a sample rendering using some other
           way of displaying it is useful. I did it using normal
           unprefixed CSS which works for everything except Safari
           where I used a prefix for the behavior. Bert and, I
           think, fantasai didn't like the prefix use.
  Florian: I can do it using a GIF, but is it bad using the prefixed
           fallback for one browser?
  smfr: Safari and iOS 9 will support that unprefixed.

  fantasai: Part of the reason tantek was arguing to allow was it
            functions as an inline test in the spec. As an
            implementor reading the spec you can see if your
            implementation does this correctly and as an author you
            can see if your browser does this. But if you add the
            prefix that doesn't work.
  Florian: I was using it on the ref side, not the test side.
  fantasai: In that case, I don't have a strong opinion.
  Florian: I can switch to doing it with a GIF. I'm not sure they're
           standard, though they work everywhere.
  fantasai: I think they're standard even if there isn't a spec.
  Florian: If the criteria to allow it is that it has a standard,
           GIFs are not.

  tantek: This is prefix in the executable code, not the example?
  Florian: Yeah.
  tantek: Then it absolutely should be allowed.
  TabAtkins: I agree.
  tantek: We've gotten exceptions for this multiple times, like
          CSS 3 UI.
  Florian: That was a slightly different battle.
  tantek: No, we have prefixed.

  plh: I'm trying to understand the motivation.
  plh: The goal isn't to say anyone can use CSS prefixes in their
       spec, the goal here is for the purpose of having a reference
       if we can't find a way that works in all existing browsers
       it's okay to use a prefix.
  Florian: I have a double example where on one side it shows what
           the property would do which doesn't work right now and on
           the other side it shows what it will do once implemented
           which I can do using existing properties except for one
           browser where I needed the prefix to make it work.
  * fantasai thinks this case is fine
  plh: Okay, thanks for the clarification.
  Florian: I think in general this should be fine, but it requires
           judgment where if the spec isn't stable but there are
           multiple interoperable implementations, but it shouldn't
           be used when there isn't wide interoperability. In this
           specific case it seemed fine.

  astearns: So we should allow this prefix in this example seems to
            be the group consensus.
  Bert: This is about the W3C site. It's not about how we ought to
        show things to people. If we want to show how something
        blinks that's fine. This is about what we can show on the TR
        page. That's where we have documents that should stay there
        forever and there we want things that should be valid and
        stable forever. We want to keep the value of the TR page as
        high as possible. I'd say find some other means of showing
        blinking.
  astearns: I don't see the future compat issue. We're not only
            using the prefix, we're also using unprefixed version.
  plh: I think we jumped that gun when we said if you want to use
       properties that aren't in REC in a CSS spec that's okay. So
       we jumped that gun in spec. At the time the question of
       prefixes wasn't presented to me. Honestly, I'll have to sit
       down with Tim and make sure he's comfortable to say go ahead.

  Florian: Should I restore the examples and then we try and publish?
  plh: You won't be able to until I sit down with Tim, but if you
       want to restore the spec go ahead.
  Florian: Okay, so I'll restore the spec.
  plh: I may have a chance later today to sit down with him. Some
       time in the next four hours.

  astearns: So we have a clear desire from the WG to allow the
            example and we'll wait to hear from plh.
  astearns: There's just two minutes left.

  fantasai: I have a quick issue: the status of will-change and
            variables which were supposed to be published as CR a
            while ago. Who has that ball?
  TabAtkins: Me.
  fantasai: Can you pass it to somebody else at some point?
  TabAtkins: Yes.

  astearns: We'll talk about resize issue next week. Houdini meeting
            at TPAC on maybe Thursday or Friday will continue on the
            mailing list.
  astearns: That's it for the week.
Received on Thursday, 17 September 2015 11:07:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:33 UTC