W3C home > Mailing lists > Public > www-style@w3.org > April 2016

[CSSWG] Minutes Telecon 2016-04-13 [css-round-display] [css22] [cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 13 Apr 2016 19:50:06 -0400
Message-ID: <CADhPm3ujrx_LQTo9fUeEn=eK_QRhHkgYLNUWzH2_0pHuvvTEvA@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Test suite metadata

  - The test submission process is being reviewed in hopes of making
      the tests more useful to more people.
  - The discussion began around where on the spectrum from the
      current metadata status and no metadata should the working
      group land.
      - It was expressed that the first step should be remove the
          pieces everyone agrees should be removed and see how much
          progress can be made.
  - Tests should be accepted if they contain the important metadata,
      even if some of the styling is off with a request to fix the
      problems on the next bug.
  - From there, the conversation moved to the build system being
      another thing obstructing tests.
      - There was general agreement that the build system as it
          stands now isn't needed, though there will still need to
          be metadata left in to get which tests apply to which spec.
      - gsnedders will do the work to remove the build system and
          see what progress that creates on testing.
  - Discussion on testing will continue on the mailing list.

Round Display

  - RESOLVED: Add 'viewport-fit: contain' to Round Display spec
  - The description of the 'viewport-fit' property will need to be
      clear about the order it occurs in with other properties.
  - The group liked the idea of having an additional attribute
      returning shape of display, however this information isn't
      currently exposed to the browser.
      - Until the device shape information is available, Florian
          will continue working on the media feature he is building
          to return if a device is round.

Planning the CR/PR of CSS2.2

  - Bert will continue looking through the errata for test coverage
      and report back to the group once he's done.


  - RESOLVED: Accept grid issue 26; adopt the language in option B
              on this e-mail:


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0228.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Daniel Glazman
  Tony Graham
  Jihye Hong
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  François Remy
  Florian Rivoal
  Alan Stearns
  Geoffrey Sneddon
  Ian Vollick

  Simon Fraser

Scribe: dael

Test suite metadata

  Rossen: Let's go ahead and get started
  Rossen: Any additional agenda items? [silence]

  Rossen: Was this added by gsnedders?
  astearns: I added it because gsnedders asked the group.
  Rossen: gsnedders are you capable of handling this for the week?

  gsnedders: I presume most of you have seen the mailing list
             discussion over the last couple of weeks. A lot of that
             comes down to tension between making it easier for
             browser vendors to contribute tests vs having more
             metadata which makes it easier for others.
  gsnedders: The question is where to go on that spectrum.
  Florian: I think even if we want to go far, we don't have to go
           all the way on the first step. We can remove the first
           hurdle and see where that gets us.
  Florian: I'd be in favor of removing everything people agree on
           and move on later.
  Florian: I'm not sure there's a browser vendor vs everyone else
           characterization because hopefully the browser vendors
           won't dump the tests, but also will pull from the same
           place. Even if they don't have metadata in their repo
           there may be implicit information like who committed the
           test that means that even if the tests don't have
           metadata, it doesn't happen that one browser has a bunch
           of new tests which has a lot failing...if that happens
           they won't integrate the tests if you can't see where
           they're from.
  Florian: Some data is useful for browsers, as a browser vendor.
           But we need to reduce.
  <tantek> any chance for collaboration? crowd-sourcing the metadata?

  dbaron: I think one of the issues...people might be not so much...
          that we ask for a bunch of stuff, but that the people who
          review tests are very picky.
  dbaron: Sometimes the right way to deal with it is say we want
          tests and like metadata, but you just wrote 500 test and
          we won't make you go back, but next time can you do this
          stuff. That's a reasonable thing to say sometimes.
  Florian: I think we are too picky in general and when people
           submit tests and they've valid and it's stylistic that
           should be allowed through. When the metadata lack makes
           it so you don't know what it's for we can't accept it.
  <fantasai> Florian++
  <tantek> is there a tl;dr summary of the mailing list thread?

  Florian: Also mentioned on the ML more than the metadata, but the
           build system might be a hurdle. We might try and remove
  Rossen: Other opinions?
  <dbaron> yes, I think having a build system is a hurdle
  gsnedders: When it comes to the build system, my understanding is
             there were a few people in the group who wanted to
             build test suites per spec which requires a build step.
             It could be no one feels that way anymore and they're
             happy to be able to extract a list of test applied to
             this spec and we don't need the build system as exists
  Rossen: Some degree of reference between tests and parts of specs
          is required so we can have the organization of spec
          progress and track what is covered. Especially when specs
          are close to REC. Anything other than that...I'm not sure
          is necessary.
  fantasai: I don't think we need a build system. There were
            historical reasons, but they don't really apply today.
            Most tests can be run in place. There's nice things you
            can get from a build system, but I don't think it's
            needed to run the tests. Even right now tests are ID by
            the file name, not build information. So I don't see why
            vendors would need to use the build information. There's
            a few XHTML will need to be fixed.
  <ChrisL> we don't really need xhtml versions of tests. we do need
           the manifests.
  plinss: The build system is generating HTML and XHTML which was
          needed before, but I'm not sure anymore. It also gets us
          the manifests which is needed. It's not something we can
          walk away from unless we rework architecture.
  <tantek> I'm in favor of dropping the XHTML versions for any CSS3
           or later test suites.
  gsnedders: If we have a manifest for the whole repo, if we have a
             way of getting which tests apply to which spec, that
             suffices for the infrastructure, does it not?
  plinss: We can make changes to the test harness to change manifest
          formats if that's what we want. The thing the test harness
          gets us a lot of good info to get a spec out of CR. It
          gives us a lot of information about where tests are needed.
          I don't think we want to walk away from it as long as we
          get benefit.
  fantasai: What we do on our end for the build system doesn't
            matter to the vendors. They can run tests in place. Now
            that we accept HTML we'll need to switch a few on the
            source format.
  plinss: I agree.
  fantasai: And for our purposes we can keep it unless we replace
            that functionality.
  <ChrisL> agree we really need spec and reference links

  <astearns> I propose we have gsnedders take the result of the
             build/metadata conversation so far and edit the wiki on
             how to submit and review tests
  <gsnedders> astearns: we also have some things pointing to TTWF.
              we should just have the wiki link to that in its

  plinss: If we're the only ones running the build system, we do
          need some metadata. Differentiate tests and references and
          the spec links. Other than that the build doesn't care
          about metadata
  Rossen: And you're suggesting this should be on us or the vendors
          submitting tests.
  plinss: I think people submitting tests tell us what spec and what
  Florian: We've been discussing this on the ML. One case is the
           simple is where test points to one part of a spec. The
           complex case is when a test points to multiple specs. In
           the first case having a directory structure that matches
           the spec could be enough and we leave the links as
           possible if people want more complex, is that good enough?
  plinss: Directory structure is metadata.
  Florian: It's less annoying to type according to most people.
  fantasai: I think it's important to have detailed info as to which
            part of a spec is being tested. If it's really
            troublesome to put in the help links than we can do the
            primary link auto. But once you're writing tests for a
            section we can have directory structure and the help
            links and then you can copy from previous tests. We
            could go either way on that. I think we should keep the
            help links because tests must test multiple sections.
  fantasai: We have concerns about too many tests in one large
            folder. If it helps to split that's a good idea. If it
            helps to have a direct link we can build that in as well.
            We have to keep a strong directory structure and vendors
            will have to map it.
  fantasai: There was one concern where if you have a directory
            structure you don't have to worry about spec links
            breaking and that's not really an issue. We move the
            sections, but we maintain their IDs.
  Rossen: Is there are this point...it sounds like we agree we need
          the metadata in one form or another continuing forward at
          least for specs going in and out of CR to be able to track
          what's covered.
  Rossen: The implementations details we can continue to debate and
          improve on.

  Rossen: I want to go back to gsnedders and make sure your
          questions are addressed.
  gsnedders: I think they are.
  Rossen: With that said, is there anything else you want out of
          this gsnedders?
  gsnedders: Not immediately. If I take an action to get rid of the
             build as we have it and see where that leaves us....
  fantasai: The only thing to make build optional is fix HTML tests.
  gsnedders: And build a manifest for everything to run the tests
             without building.
  fantasai: There were a few tools we wanted...a linter.
  gsnedders: If we get rid of a lot of the build system we slowly
             rewrite until we have that.
  fantasai: A tool that can run in place and link the manifest in
  plinss: That's fine by be but there's code per spec manifest as
  Rossen: We can continue to get details on the ML.

  ACTION gsnedders get rid of the build as we have it and see where
         that leaves us
  <trackbot> Created ACTION-766

Round Display

Setting the viewport into non-rectangular display

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0066.html
  jihye: We discussed the robustness of CSS.
  jihye: In general the viewport takes the shape of the display. So
         the corners get clipped when it is displayed on round. So
         the idea to solve this is setting the viewport as the
         inscribed square. A think a new descriptor can do that.
  jihye: I suggest a new one as 'viewport-fit' that has a value as
  jihye: Florian suggested to add 'cover' and 'auto' value. 'Cover'
         would have the viewport as the bounding box of the display.
  Florian: That's one place I disagree. We need to have two values,
           or else it's not a switch. There's 'contain' and 'cover'.
           The default if we ignore auto is 'contain'. So they have
           everything visible and there's no disappearing content.
           'Cover' should be used by authors who know how to deal
           with it.
  Florian: I'm adding an 'auto' value that is the same as contain
           with some leeway. So having a strict rectangle makes it
           smaller than needed. A rectangular screen with slight
           rounding it's not that bad to miss a part.
  Florian: It's similar to contain with some leeway. I don't know if
           it's essential.
  Rossen: It sounds too magic and I can see a lot of cases where
          it's unpredictable.
  <TabAtkins> My office is being loud right now but: I don't think
              we should 'contain', by default or at all, really. It
              hides a ton of the screen on a round display.
  <TabAtkins> Like, I think the "some part of the viewport is
              hidden" problem is *less bad* than "the screen has
              huge gaps on each side and is really tiny" problem.

  fantasai: We talked at the F2F about a UA might want it larger
            than the contained rectangle by an amount and use the
            scrolling to let the user see the corners. So you do a
            circle and have a slightly bigger rectangle the user
            could scroll down. That would be reasonable to want by
            default. Whatever we have as default should allow that
            thing and let the UA be more intelligent.
  Florian: So do you agree with 'auto', 'contain', and 'cover' with
           more magic on 'auto'?
  fantasai: Yes.

  Rossen: How does scrolling or panning or refitting the visual have
          anything to do with size of them. You're describing two
          orthogonal features.
  Florian: They're not orthogonal. 'viewport-fit' does two things.
           If we go with the device orientation spec it sets the
           size of the layout viewport before you apply @viewport
  Florian: The 'viewport-fit' switches that size being the one that
           covers and fits in. The other thing is about the visual
           viewport. Its size must fit in the screen and you must
           place it tin the screen.
  Florian: While we're speaking about size and position of visual
           viewport, having wording that says it must not be
           strictly in the middle doesn't sound insane to me.

  MaRakow: You might have partially answered my question, but I'm
           trying to figure out exactly the implications in terms of
           how this enters into calculating of used layout viewport.
           Especially when using width and height properties. What
           are those relevant to at that point. I'm not sure a
           'contain' is simple to calculate. Such as a rounded
           rectangle you could favor vertical over horizontal you
           could expand or have a perfect square.
  MaRakow: It might be interesting to rephase instead of a fit rule
           it's about controlling the initial viewport.
  MaRakow: Also it interests me what it would mean to expose
           negative coordinates so you could see less than 0 on x
           and y. I'm not sure what that would do or if we would
           have compat issues. We should think that through.
  Florian: I think what I had in mind was more blunt than what you
           described. The switch between 'cover' and 'contain' it
           wasn't enough power for the author to control a long vs
           tall viewport to meet one end. It was set up two shapes,
           one that covers the whole screen and one that fits in it.
           It's not as flexible. Maybe we want that flexibility.
  MaRakow: Even if you don't offer configurability, maybe it's not
           having rounded rectangle but it's circular.
  Florian: I agree the email is too short to be a full spec, but in
           general where that rectangle is is up to the UA. As long
           as you pick one in the screen you're good. If you pick a
           silly one, that's bad UA. If there's multiple you as a
           browser do what you think is best.

  <fantasai> probably want to recommend 'contain' being the largest
             possible rectangle that would fit
  <fantasai> bias to landscape
  <MaRakow> bias to larger dimension?

  Rossen: So in summary...it sounds like we agree on the three
          values. Is that correct proposal?
  Florian: It's my proposal at least.

  jihye: Yes. I have something of interest...there are descriptors
         about specifying the builders like height. How the priority
         will be? I think viewport-fit is higher priority over height.
  Florian: I think so too. I think the spec currently lacks vocab.
           The space in which the viewport is...which screen do we
           use? The one that fits in or fills and once you pick that
           you have all the other rules. Once you pick contain you
           can pretend the screen isn't round at all.
  Florian: We need to be careful when writing that we make that
           clear, but that's the intention.

  <BradK> Can the visual viewport not clip the content that falls
          between the contained visual viewport and the actual
          device edge?

  jihye: OK. Can I do the spec about the 'viewport-fit' in round
         display first?
  Florian: I think it would be...the problem would be there is
           missing vocab in device adapt spec. It would be better if
           we had some terms there.
  Florian: I think it makes sense in round-display for now and if we
           discover missing terminology that should be elsewhere we
           add it there and you refer to it.
  MaRakow: I'd be curious to see what the text looks like. It's hard
           to evaluate without text. But if it becomes a rule for
           initial viewport it might make sense to move it to device.
  Rossen: Let's start with the proposal added to round display.
          We'll have text and go from there.
  Florian: Yeah. I think it'll eventually migrate.
  Rossen: Let's decide once there's text.
  Rossen: In that case, any objections to proposed addition of
          viewport-fit: contain added to Round Display spec?

  RESOLVED: Add 'viewport-fit: contain' to Round Display spec

Additional attributes returning shape of display

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Apr/0110.html
  jihye: The device radius in CSS Round Display detects the shape of
         the display it enables us to apply different styles
         according to the display shape. We still need to know the
         device shape when we implement apps with JS. For example
         scrolling is JS. So it's necessary to detect the shape of
         the screen.
  jihye: For example, in ??? there is a JS to detect if the shape is
         round to support round display. CSSOM view has information
         about the output screen device.
  <jihye> https://www.w3.org/TR/cssom-view-1/#the-screen-interface
  jihye: So I think it can also give info about the shape of the
         screen. It returns true when rounded. With this attribute
         we can know the shape of the display.

  Rossen: Comments?
  <TabAtkins> I agree that directly exposing the shape is good.
  Rossen: Suggestions?
  Florian: I tend to comment on round-display, but OM View is out of
           my area.
  Rossen: As an API having this as a boolean return true when
          something is circular sounds wrong to me.
  Rossen: You want the API to return the shape and then it's up to
          the author. If you want more boolean feature it's more of
          a media feature and should be dealt with that way.
  fantasai: I think I agree the API should return a shape, but it
            can return false for a rectangle. That was you use as a
            boolean and get shape.
  Rossen: And a rectangle with 0.1 rounding, is it a rectangle?
  Rossen: If we can avoid we should.
  Florian: And true and false to MQ?
  Rossen: Yes.
  Rossen: Any other feedback?

  Rossen: So is there anyone objecting to adding this to the OM view?
  Florian: I have a question. Last time we talked about this we
           discussed at the OS level you don't know the shape. So a
           boolean we can do, but the shape being returned isn't
           available to the browser.
  Rossen: I'm not sure I follow.
  Florian: So an API that returns a shape for not-rectangle and I
           think last time we talked about this someone mentioned
           that this isn't typically made available by the OS. At
           the OS you can have a boolean returning round. If that's
           the case we can't do this API
  fantasai: Can we do boolean now and expand later?
  Florian: If we just do boolean, why not have it as a MQ? What does
           it get us over a MQ?
  fantasai: Fair point. We should wait until we can implement the API
  <tantek> +1 to that
  Florian: Maybe I'm wrong, but I thought last time we discussed we

  Florian: I think it was Android that did something. It is just am
           I a circle.
  Rossen: And once they support more they'll have to add.
  Rossen: In that case I'm siding a lot more with keeping this as a
          MQ if we need boolean. And later add a feature for
          geometry when it's available.
  Florian: And I'll work on media feature this week.
  Rossen: And so we need no new resolution because Florian has an

  Rossen: jihye did we miss anything?
  jihye: I want to add something. If I understand correctly I
         suggested an attribute that returns information about shape
         of display. It returns the boolean value...
  Florian: What we're saying is there's 2 possible APIs. One that
           returns a boolean that says if I'm a circle and that's
           not needed because I'm writing a MQ for it. The other one
           returns information of geometry of the shape and that
           would be useful, but the OS doesn't give the browser that
           info and that can't be done.
  jihye: I thought of one that would return the coverage of the
         corners. That can't be implemented?
  <joone> I think Android wear only has the api for checking the
          display shape whether it is round or not.
  Florian: As far as I know, OS as of today have no API to inform
           the browser, or have extremely basic that just say I'm a
           circle. I'd like someone who knows more about this. But
           at the F2F I think we said that Android is the only one
           that gives you anything and it's a boolean.
  Florian: If we get more than that we can do the API.

  Florian: Can someone take an action on checking?
  Rossen: It sounds like that would be a good action for someone
          close to Android.
  Rossen: We have members from Google. Or jihye if you have
          implementor experience and can check with engineers that
          would help.
  Florian: Can we action OS vendors to see what their OS offers?
  myles: Ours doesn't offer anything.
  Rossen: I'm pretty sure ours doesn't offer anything.
  Florian: If anything it's android.
  Rossen: So currently they have the boolean, as per our current

  Rossen: With all that information, is there anything else to cover
          on this topic jihye?
  jihye: No.
  jihye: I think we discussed about all the things.
  Rossen: Thank you

Planning the CR/PR of CSS2.2

  Rossen: We have 6 minutes. 1 flex, a number of grid, CSS OM View,
          and CSS 2.2. Out of these...bert are you on the phone?
  Bert: Yes.
  Rossen: Is 2.2 this week?
  Bert: It's not that urgent. If people have advice...there's 3
        questions on this. 1) Testing: how many? what do we have? 2)
        What is the next version of 2.2, do we need a new WD? 3)
        What time scale is reasonable...end of summer, before?
  Bert: If there's time for that today sure, but it's no hurry.

  Rossen: I'm bringing this up because I know plh had some concerns
          on this and we want to make sure this is on track and we
          have a good plan to move us from 2.1.
  Rossen: With that said, back to your questions...testing.
          Everything in 2.1, how much change is there so we need
          test coverage?
  Bert: I haven't checked everything. I looked at the errata. Some
        are informative. Some are normative and have tests. I found
        a few that need tests. I expect we need a handful more tests.
        I've made less than 10. I haven't checked all of them yet,
  Bert: So far a handful of tests is needed. The ones I tested were
        impl already so I don't expect trouble with impl. But I
        haven't checked them all if others know more.
  Rossen: I know you and antonp were handling the errata.
  Bert: Yes, there were some complex issues with margins and boxes.
        So I'm trying to test those. It's hard to say how much time
        it will take.
  Rossen: Sounds like you need a bit more info before we can decide
          on how much testing is needed. Why don't you come back to
          us with that information?
  Bert: That's fine. I'll have something next week or week after.
  Rossen: Thank you.

Grid Issue 26

  Rossen: I'm fine on that one. I agree with the resolution.

  RESOLVED: Accept grid issue 26; adopt the language in option B on
            this e-mail:

  astearns: We're at the hour.
  Rossen: Since we're at the top of the hour, let's call it meeting adorned.
Received on Wednesday, 13 April 2016 23:51:07 UTC

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