W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[CSSWG] Minutes Telecon 2014-07-09

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 10 Jul 2014 11:28:43 -0400
Message-ID: <CADhPm3uJ7YG1bFQVEmjZ7R+_HGr6+5aaVE7MABrsiquzayBN4A@mail.gmail.com>
To: www-style@w3.org
Upcoming F2F
------------

  - Bert informed the group that he has begun the wiki for the next
      F2F and encouraged people to add their names if they know
      they'll be attending.

Exposing Color Parsing
----------------------

  - There was general support for TabAtkins's proposal and he'll add
      it to Color 4.

Extrinsic Sizing of Controls
----------------------------

  - It was agreed that the issue raised by gregwhitworth was a bug
      in implementations, not an issue with the spec.

CSS Ruby
--------

  - fantasai updated the group on her status with Ruby and is
      anticipating feedback from Kawabata and more conversations
      with Boris.

Grid Layout
-----------

  - fantasai outlined her current proposal for simplifying grid
      layout error handling.
  - There was general approval from the group.
  - She will seek a resolution next week after Rossen has had time
      to review the proposal in more detail.

Flexbox Update
--------------

  - At Rossen's request, fantasai also gave an update on Flexbox
  - She said she was close to a complete DoC with only a few issues
      that still need to be solved.

Korean vs Japanese Justification
--------------------------------

  - In general, the group felt that authors should be encouraged to
      language-tag their work to help avoid problems with the
      behavior of auto.
  - Since many documents aren't language tagged, everyone also felt
      a solution did need to be developed.  Suggestions included:
      - Re-instituting the inter-character property
      - Accepting that using auto limits some features and thus
          encouraging language-tagging
      - Creating a way to auto-detect the dominant script
  - The discussion will head back to the mailing list for further
      feedback and hopefully a good compromise on default behavior.

CSS Background Issue
--------------------

  - Everyone agreed that the current behavior of display: none and
      visibility: hidden is correct and should be written into a
      spec.
  - SimonSapin will come up with proposed text for an errata to
      CSS 2.1 that the group can ratify.

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

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins (IRC Only)
  David Baron
  Adenilson Cavalcanti
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Sylvain Galineau
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Taichi Kawabata
  Philippe Le H├ęgaret
  Peter Linss
  Michael Miller
  Shinyu Murakami
  Edward O'Connor
  Matt Rakow
  Simon Sapin
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Bruno de Oliveira Abinader
  Anton Prowse
  Florian Rivoal
  Dirk Schulze
  Lea Verou

  Scribe: dael


  plinss: Let's start. Hello everyone. Is there anything to add to
          the agenda?
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0137.html
  fantasai: There was a message from SimonSapin on CSS-background
            that seems straightforward (link above). If we have time
            we can look at that.

  bkardell: I don't have anything, but I was wondering what the
            policy was on order. The last item is what I'm
            interested in and I have to leave early. Any way to
            shuffle the order?
  plinss: We can certainly shuffle, but TabAtkins_ is the one that
          mentioned it and he's not here.
  bkardell_: We can maybe do it next week.
  <TabAtkins_> What's that last item? In the car now, so I can talk
               for a bit in irc.
  <fantasai> color parsing
  <TabAtkins_> Kk. Of your okay with me being irc-only, I can talk.
  <TabAtkins_> Also I'm on a phone keyboard.

Upcoming F2F
------------

  bert: We started the prep for food and stuff, the room is reserved.
  bert: I made the page on the wiki with registration information.
        Please fill in your name. The name is needed for network
        access, so it's important.
  bert: I put a few hotels around here, but you might want to look
        in surrounding towns. I don't know if people want rental
        cars, but you can maybe set up carpools .
  bert: If you have any information to share, use the wiki. Or add
        topics for discussion.
  bert: That's all I had to announce. Were there any questions?
  bkardell_: No question, but thanks for putting it together.

  <sylvaing__> is there a wiki page for this meeting?
  <TabAtkins_> Yes.
  <Bert_> http://wiki.csswg.org/planning/sophia-2014
  <sylvaing__> Ah, the page is not yet linked from the meeting
               planning page

  bert: The page still has holes to be filled in, but there's some
        information already.
  plinss: Thanks.
  plinss: It looks like TabAtkins_ is on IRC so lets move the order.

Exposing Color Parsing
----------------------
  <plinss> http://lists.w3.org/Archives/Public/www-style/2014Jul/0106.html

  plinss: TabAtkins_ sent this in about exposing some functions for
          color parsing. bkardell_ you said you were interested, do
          you want to speak?
  bkardell_: He said in his e-mail he was planning on looking at
             deeper integration with CSS OM and I was curious what
             exactly this might initial.
  bkardell_: According to this you can make your own color format
             and that means you could express color formats in ways
             that were reflected in CSS or weren't but what form
             would they stringify...
  bkardell_: It may be difficult with just IRC.
  <TabAtkins_> Ah, the "deeper integration" is what I talked about
               at the January f2f.
  <TabAtkins_> The JS Value Objects-based proposal.
  <TabAtkins_> But that's still blocked on JS, so no need to worry
               about that for now.

  plinss: I presume with your own format it's just stringify and
          parsing and you'd get a POC format that you could assign
          directly.
  <TabAtkins_> Yup, plinss. "var x = RGBAColor.fromMySpecialColor
               (foo, bar); el.style.color = x; /* stringifies to an
               rgba() function automatically */"
  <sylvaing__> TabAtkins, what are 'foo' 'bar'
  <TabAtkins_> sylvaing__: Whatever you want - that's an author-
               defined function.

  plinss: Since TabAtkins_ is only partly here, any other opinions?
  plinss: Is this worth pursuing?
  SimonSapin: There's 2 things here. One is exposing the parsing of
              CSS color from a string to RGB numbers and I think
              that's fine.
  SimonSapin: The new color format, that's adding support for things
              that would be added in style sheets.
  bkardell_: The proposal includes both. It says authors can define
             their own color format by adding to RGB with
             appropriate color tags. If we're talking about the
             proposal that's part of it.
  <TabAtkins_> They explicitly did "RGBAColor.prototype.
               fromMySpecialColor = function(foo, bar) { ... };"
  <TabAtkins_> Sorry, scratch the ".prototype".

  plinss: I don't presume those color caps would be embeddable raw
          unless we really open parsing. This is only for authors
          programatically for whatever IO format, they can modify
          style sheets, but not add this as CSS source.
  bkardell_: It seems that if you did this from the prospective of
             serialization type, is it worth being able to
             differentiate browser native and user defined?
  plinss: I'm not sure you'd need to. We have serialization for
          color so if you do an entire stylesheet it would go back
          to RGB. It wouldn't attempt another model because they
          style sheet wouldn't know what that format is.

  <TabAtkins_> bkardell_: I am *not* talking about extending CSS
               itself (yet). This proposal is just to produce a
               Color object that has the right hooks that authors
               can use it for their own needs, beyond just CSS.
  <TabAtkins_> (Actually extending CSS for new color types will wait
               for custom functions.)
  <sgalineau> TabAtkins: ah, check. I thought you were describing a
              proposal, not a practice
  <bkardell_> tabatkins: I'm wondering really if RGBAColor.
              serializationTypes would differentiate an author
              defined serializationType, for example
  <TabAtkins_> bkardell_: It doesn't differentiate, no.
  <TabAtkins_> bkardell_: But the default serializer is rgba(), and
               having the ability to serialize is distinct from the
               ability to parse.
  <TabAtkins_> bkardell_: Like I said, in the future custom
               functions should take care of actually extending CSS.
               For example:
  <TabAtkins_> Eh, don't wanna write out an example right now. It'll
               look something like the Custom Pseudo-classes bit.
  <bkardell_> TabAtkins_: Yeah, it was mainly about is there utility
              in being able to thinking about future proposals...
              maybe I'll comment privately || on ML

  plinss: Other opinions?
  SimonSapin: Sounds good. Let's do it.
  plinss: I'm not hearing objections. Let's accept the proposal and
          add it to CSS Color 4 or the OM as appropriate.
  <TabAtkins_> Okay, I was going to ask what spec to put it in.
               Color works. ^_^

Extrinsic Sizing of Controls
----------------------------

  fantasai: I was looking at the e-mail, I don't think you meant
            extrinsic, I think you meant explicit.
  gregwhitworth: I'm referring to exterior width. I know vendors get
                 antsy about what's on the interior.
  fantasai: So extrinsic isn't the word. I think this is in CSS2.1
            where we spec where the scrollbar goes and takes room.
            It's not super clear but it spec the Firefox behavior
  fantasai: Here's the response.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Jul/0143.html

  rossen: For all I know we have a bug there for not taking
          scrollbar out of min-width
  fantasai: Min-width and width shouldn't be different.
  rossen: I agree. I don't think 2.1 has text for that, but I agree
          the intent is they should be the same.
  fantasai: They're defined as equivalent in their effects.
  rossen: Scroll-bar size is taken out of use width.
  fantasai: min-width effects the content box, but we take out the
            scrollbar once you form a containing block. So the
            content inside is in a smaller box.
  rossen: I think gregwhitworth's example shows issues with IE and
          Chrome. Other than that I don't think we need spec changes.
  rossen: Unless gregwhitworth thinks otherwise.

  gregwhitworth: I wanted to make sure we're on the same page.
  rossen: The point is valid, we should converge. I think the spec
          is clear and we need to fix bugs.
  rossen: Anything else on this?
  gregwhitworth: Nope.
  fantasai: Nope. If we want to clarify 2.1 we can.

CSS Ruby
--------

  fantasai: The update is that we've been working on the box model,
            particularly anonymous box.
  fantasai: I've been doing that on the list. Mozilla is
            implementing the rules so we're getting good feedback.
  fantasai: My goal is to get Boris to agree the rules are correct
            and than get a new WD. There is stuff with Ruby layout I
            haven't drafted.
  fantasai: We've also defined white space by making anonymous boxes
            that are similar to existing, but they don't pair. If
            there's pairs, they get paired with anon boxes in
            another layer
  fantasai: For nested I'm trying to handle with layout rules rather
            then trying something fancy in box generation.
  fantasai: That's the overview. If there's interest I can do more
            details.

  plinss: Okay. No questions?
  plinss: I know everyone is excited about Ruby
  fantasai: Is there anyone that wants to review that I should wait
            for feedback? .
  <kawabata> I'll check it closely.
  fantasai: Okay. I'll wrap up edits with Boris and get a check from
            kawabata-san.
  <gregwhitworth> fantasai: I do think extrinsic is the correct term
                  per the sizing spec as I don't want controls
                  dimensions to be determined by the contents if
                  stated the the author .

Grid Layout
-----------

  rossen: I was in and out and couldn't review.
  rossen: I got fantasai's e-mail, but I'm just not ready. If we
          want to make a decision I'd ask to postpone. If this is
          just an awareness thing, that's fine. But if you want
          consensus, I'd prefer we do this next week.
  fantasai: I'll explain, but not resolve.

  fantasai: For Grid we have 2 properties in any dimension. There's
            grid column start and end. These can be number of lines
            or a span of this many lines or names lines.
  fantasai: We have error handling. If you specify, for say, a line
            that doesn't exist. Or a different case if you're
            spanning for 5 lines and there's only 4. We had various
            rules for different cases for what if you don't have
            enough.
  fantasai: What we did was we realized we could have a simple rule
            that says there's an explicit grid and that's the one
            you set up. There's also an implicit grid where if you
            position an item with numbers such that it's no longer
            in that explicit grid, they're still in that implicit
            grid.
  fantasai: We decided we could simplify by saying if you can't find
            a named line, assume that the implicit grid has those
            lines and count in there. It's simple and consistent.
  fantasai: It can give you odd results, but that's good because it
            gives you things that are noticeably off.
  fantasai: Those are the main advantages of this new set of rules.
            We're looking for review from anyone with an opinion.

  rossen: I don't see anything wrong with the approach, I have to
          sit down and work through the cases and see if this is
          sufficient.
  rossen: If it is, I'm fine.
  fantasai: If you're interested, send your comments. Otherwise well
            close the issue with rossen's opinion next week.

  plinss: It sounds like a reasonable approach. Any times there's an
          error the author won't get it. I think this is as good as
          we'll get.
  rossen: It'd be better to keep the error as dominant and simple as
          possible. We don't want to "help" them too much. We want
          it to be outrageous so that it's obviously an error. Let
          me sit down and I'll have a better opinion next time.

  fantasai: Because we have a rule with just numbers and not names,
            if you say 7th and there's only 5, we create a 7th.
  fantasai: If you think of named lines creating an implicit grid,
            we just do the name thing. We add named lines until you
            have the right number.
  plinss: The problem is if people are adding named, there's likely
          a pattern and the author will expect a pattern, but I
          don't think we want to create an algorithm for that.
  rossen: I agree, especially in the error case.
  rossen: It makes sense.
  fantasai: Yep.

Flexbox Update
--------------

  rossen: While we're on grid, related question. Do we have anything
          for flex box? Where do we stand?
  fantasai: We fixed a bunch of issues. A lot was responses to the
            changes. Some comments were other noticed errors.
  fantasai: There's 2 issues that aren't quite sorted.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325
  fantasai: Here's the DoC.
  fantasai: We have an open issue on intrinsic aspect ratio items
            and minimum sizing.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-19
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-16
  fantasai: There was a couple we fixed and need review, I think
            issue 19. 16 is open. And then static position stuff we
            haven't sorted.
  rossen: For the auto position abspos?
  fantasai: Yeah. That's issue 12.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-12
  rossen: Okay.

  rossen: It doesn't sound far from done.
  fantasai: It's those three things to look through. 16 and 19 need
            the most review because they're confusing issues.
  fantasai: I think 16 has comments from dholbert.
  fantasai: Once we're through those we'll have a complete DoC to
            review with the WG and do a new LC. We really appreciate
            comments because there's a lot of tricky things
  rossen: Thanks. Sorry to hijack the agenda

Korean vs Japanese Justification
--------------------------------

  fantasai: koji is trying to get comments from the Korean community.
  fantasai: There are Japanese and Chinese docs that are formatted
            similarly. Korean isn't though. Most modern docs are in
            Hangul, but some have Chinese characters.
  fantasai: So Chinese characters are a part of Korean, but not
            common. Korean does have spaces and uses spaces to just
            like Latin languages.
  fantasai: Chinese and Japanese don't use spaces to justify. What
            happens in a line of Japanese, you'll have only 0 or 1
            space and if you use spaces to justify you'd have huge
            spaces. Instead you space between characters.
  fantasai: This has created a problem between Korean and Japanese
            documents where just Korean wants to use the spaces to
            justify.
  fantasai: I think one browser spaces between Chinese and Japanese,
            but not Hangul which creates some problems with mixed-
            script text. We're looking for a compromise that's
            appropriate for untagged content. If it's language
            tagged you're fine, but when it's untagged that's what
            we're stuck on. While the spec won't require anything,
            we wanted to have a suggestion.

  SteveZ: Question. Clearly the existence of either Hangul or the
          various kana in Japanese gives you a hint of the language,
          but that requires pre-scanning.
  fantasai: So far we're tried to avoid heuristic detection. If we
            built that in it would be a significant paradigm shift.
  fantasai: We're trying to avoid heuristics and only rely on tags
            and properties.
  SimonSapin: Would it make sense to look at language?
  fantasai: This is when a language tag isn't present.
  SteveZ: Anyone looking at the page could tell you what language.
          It'll seem strange to the user that they system can't
  fantasai: If the WG wants to go that route we can. I think there
            was a text-script property before where you auto-detect
            the dominant script and if it's wrong you can tag, but
            so far we've avoided auto-detection.

  dbaron: I'd rather encourage people to language-tag their content
          correctly.
  <bkardell_> +1 to dbaron's comment
  <SimonSapin> +1 dbaron
  SteveZ: I think...I agree that having tagging on something is the
          best way to go, but we've already learned people copy from
          others and do the minimum to get it to look right and I
          think browsers in Korea may get tuned to make a Korean
          assumption and it works if you don't take it out of the
          context.
  fantasai: I think that used to be true, but no longer.
  SteveZ: You think authors are tagging?
  fantasai: I think browsers aren't shipping biased engines of
            layout versions.
  SteveZ: It's not much of a bias to say assume Korean.
  fantasai: It's still a bias.

  bkardell_: There's language setting in the OS.
  fantasai: We don't use the OS because it would make our page look
            different depending on what computer you're looking at.
            We want to depend only on page content.
  SimonSapin: Firefox has a character encoding fallback based on the
              local of the user. That's legacy content and I don't
              think we should add a new behavior.
  plinss: I agree. If we want to encourage authors we can define the
          default as the worst behavior.
  dbaron: There's enough pages without language tags that we can't
          do something horrible, but we can do something like make
          hyphenation not work.
  <bkardell_> this doesn't seem horrible if there is no way to tell.
  fantasai: So we can make spacing look not optimal, but that's the
            worst.

  SteveZ: So is plinss suggesting something that doesn't work in
          either case and dbaron says that's not an option?
  fantasai: I think dbaron is saying don't break stuff, but you
            won't get the best behavior if you don't language-tag.
  plinss: I was trying to encourage authors to language-tag, which
          means as little magic and markup as possible.
  ??: Can you treat justification so it doesn't work without
      language tagging?
  fantasai: I think the default should be better than now where it
            doesn't work for CJK and does for Latin. We can't make
            it worse than it is. All space separated languages work
            now.
  SteveZ: If the current state is it doesn't work for non-space-
          separated languages we can leave it to make people tag.
  fantasai: We dropped the inter-character value and there's a bunch
            of pages that currently spec using inter-character, but
            since we dropped that and assumed auto would handle it,
            we have to make sure auto does.
  SteveZ: This sounds like a problem we made.
  fantasai: A bit. But I don't think Firefox supports it so it's not
            completely us.
  SteveZ: We dropped inter-character because?
  fantasai: The argument was auto should be able to do it. We have a
            couple of solutions that approximate the right thing,
            but not quite perfectly. The discussion is, of the
            possible compromises, what's the best one?
  SteveZ: I haven't thought about it a lot, it seems inter-character
          should come back.
  fantasai: Inter-character isn't needed if you language-tag
            correctly, but people are using inter-character to fix
            their layout, their pages.
  glenn: They didn't understand the effects of language tagging.
  fantasai: Yeah.

  koji: I think I'm tending toward inter-character, but I'm awaiting
        the replies from Korean community. There's a possibility we
        want it back.
  koji: It may be correct or not, but we need a little more
        distinction.
  plinss: It sounds like we loop back with more feedback.
  fantasai: If there's ideas for a compromise for default rendering,
            please comment on the thread.

CSS Background Issue
--------------------

  SimonSapin: It's about backgrounds of the canvas.
  SimonSapin: What happens if we specify display: none or
              visibility: hidden. It's not clear in the spec what
              should happen, but we have strong interop that the
              background is still shown with display: none, but not
              with visibility: hidden.
  dbaron: There's a test case Hixie wrote a while ago. There was one
          for display: none and filed it as a bug against all the
          browsers.
  SimonSapin: We should have a corresponding statement in the spec.
  dbaron: Sure.

  <MaRakow> Do you happen to have a link to that test case?
  plinss: Okay. Everyone agree?
  Rossen_: Any reference to the test cases?
  <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Jul/0137.html
  SimonSapin: Here's the link with simple test cases.

  fantasai: I don't have much opinion, but whatever we do should be
            consistent with how we do writing mode direction and
            overflow propagation.
  plinss: If you're in a display: none situation, will any of the
          properties have an effect?
  plinss: All you'd draw is a canvas
  fantasai: You can detect overflow: scroll and that might have an
            effect depending on implementation.

  SimonSapin: Do we only get writing mode direction from the root
              element?
  Rossen_: I think for IE we always propagate from body or HTML.
  Rossen_: We treat it the same way to the root element which HTML
           spec says that we take those and leave body so it has a
           chance to redefine for overflow or writing. If HTML
           doesn't have it we take it from body.
  SimonSapin: The spec says don't do that.
  Rossen_: Which?
  <SimonSapin> http://dev.w3.org/csswg/css-writing-modes/#direction
  SimonSapin: Link above
  <SimonSapin> "Note that the direction property of the HTML BODY
               element is not propagated to the viewport. That
               special behavior only applies to the background and
               overflow properties."
  Rossen_: That spec was written 5 years after we did that
           implementation. Maybe it now says something different,
           but that's what we do.
  Rossen_: It's interesting that it deviates from how we handle
           overflow. I would expect the same.
  fantasai: We had a legacy constraint that we were hoping wasn't
            there for direction.
  fantasai: We wanted authors to tag the root.
  Rossen_: If you haven't implemented writing-mode, maybe. If you've
           had it for a long time then you have an issue and if you
           write ignoring that, you can avoid the issue.
  fantasai: This is direction. It's been around since the 90's.
  fantasai: Everyone's implemented it.
  Rossen_: Right.
  <plh> (fyi: the note was including in the FPWD of writing modes
        back in 2010, but it's not part of CSS2.1)

  plinss: Any conclusions?
  SimonSapin: For writing-mode and direction properties this
              propagation only applies to principal writing mode
              which is only used for paged media.
  <SimonSapin> http://dev.w3.org/csswg/css-writing-modes/#principal-writing-mode
  Rossen_: Would you expect different for regions?
  fantasai: Regions wouldn't need principal writing mode. It has its
            own thing.

  plinss: We're low on time and should wrap up. I think we agree we
          want to spec current behaviors, at least for background
          properties. Where is that?
  fantasai: Backgrounds and borders 3.
  plinss: not 2.1 errata?
  fantasai: We could do that.
  Rossen_: 2.1 errata would be nice.
  plinss: So we'll call it 2.1 errata
  <plh> is it possible to have a test case for this erratum?

  fantasai: Bert, can you do that?
  bert: I can if I know the text. What is it?
  fantasai: SimonSapin can you write one?
  SimonSapin: Okay.
  fantasai: SimonSapin will write proposed text, we can ratify it,
            and you can make the errata.
  plinss: Anything we want to do with propagation of the other
          properties, or leave it for now?
  Rossen_: Let's do it separately.
  plinss: Okay.

  plinss: That's the end of the hour and the agenda. Thanks everyone
          and we'll talk again next week.
Received on Thursday, 10 July 2014 15:29:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 July 2014 15:29:11 UTC