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

[CSSWG] Minutes and Resolutions Seattle F2F 2011-07-24 AM: IVS, Flexbox, HTML5

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 29 Jul 2011 17:17:38 -0700
Message-ID: <4E334DA2.7070102@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
IVS Feedback

   - RESOLVED: Send fantasai's draft as official comment from CSSWG on Unicode PRI184


   - RESOLVED: Use flex-wrap: wrap | nowrap in place of flex-lines: single | multiple

   - Discussed ways of representing flexbox item flow directions as a property. No
     conclusion yet.

   - Discussed alignment of flexbox items. No conclusion.

   - Proposal presented for 'true-center' alignment in flexbox. No conclusion.

   - Discussed 'display-inside' and 'display-outside' split of 'display' property.
     No conclusion. Tab to collect use cases.

   - Discussed handling of abspos children of a flexbox. Various unhappy with the idea
     of copying the nonsensical behavior from tables, but there was no solid alternative

   - Discussed block-in-inline splits within a flexbox and implications of the box
     generation model.


   - It was pointed out that while the HTMLWG and CSSWG have goals that align and
     seem to mostly agree on the dividing line between their scopes, communication
     between the groups has been lacking.

   - Potential issues raised include:
       - selectors used in HTML5 that are not defined in any CSS draft
       - lack of disabled attribute for style sheet links
       - references to CSSWG editors' drafts rather than official /TR drafts
     Tantek created a wiki page to track issues:

====== Full minutes below ======

   Tab Atkins (Google)
   David Baron (Mozilla)
   Kimberly Blessing (Comcast)
   Arron Eicholz (Microsoft)
   Elika Etemad (Invited Expert)
   Sylvain Galineau (Mozilla)
   Daniel Glazman (Disruptive Innovations)
   Arno Gourdol (Adobe)
   Vincent Hardy (Adobe)
   Molly Holzschlag (Invited Expert)
   Koji Ishii (Invited Expert)
   John Jansen (Microsoft)
   Brad Kemper (Invited Expert) via IRC
   Peter Linss (HP)
   Divya Manian (Opera)
   Alex Mogilevsky (Microsoft)
   Florian Rivoal (Opera)
   Alan Stearns (Adobe)
   Shane Stephens (Google)
   Anne van Kesteren (Opera)
   Steve Zilles (Adobe)

Scribe: Arno


   Let's talk about the agenda… Looking at the wiki
   A few requests have been recorded, based on people's presence
   Nothing planned for today yet, lots for tomorrow
   ?: we could talk about flexbox today
   Need to talk about 2 next F2F
   Adobe has proposed Bucharest, Romania as a possible location.
          Would be nice in spring.
   Kimberley: Comcast could host in Philly
   glazou: I can look into hosting in Paris
   glazou: first items for today?
   fantasai: ISV feedback, we should send today
   glazou: we should add testing to agenda
   <fantasai> Introductions going around
   <fantasai> Molly notes that she is no longer working for Opera ->
              individual Invited Expert

   glazou: let's start w/ ISV
   glazou: let's start monday with object model, then regions/exclusions
   finish w/ gradient if we have time in the morning
   writing modes and grid in the afternoon... and positioning

IVS Feedback

   any report on what's happening
   <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JulSep/0087.html
   <fantasai> latest version
   fantasai: haven't received feedback on this version yet
   fantasai: will send to unicode, adobe, hanyo denshi folks and will cc style
             and internationalization
   glazou: steve, happy with the proposal?
   steve nods
   glazou: RESOLVED. Send the comment


   glazou: next up: Flexbox
   <alexmog_> http://wiki.csswg.org/spec/css3-flexbox
   alex: the major issue to discuss is getting multiline to work with everything
         else and look at where we are with flex definition and flex units
   alex: ideally, talk more about alignment.
   alex: a bit worried about it, lots of different options
   alex: will need whiteboard to draw pictures...
   alex: let's start with multiline and direction
   alex: newer proposal is to use no-wrap, wrap and balance as options
   alex: doesn't *have* to be there, but it's a possibility
   alex: preferences toward wrap/no-wrap/balance vs. single/multiple
   fantasai: wrap/no-wrap is easier to understand, more similar to how we
             wrap text, whitespace
   Davidb: text-wrap has the default the other way around
   tantek: spelling in white-space has no dash
   it is generally agreed that this was a mistake
    * arronei time-machine: <integer>
   steve: we also use the word "wrap" in exclusions, in a different way
   alex: exclusion wrap causes exclusion to happen, text-wrap allows it to happen
   tantek: can we capture that as an issue for exclusion to resolve ?
           i.e. consider a different term
   RESOLVED: use wrap/nowrap
   <tantek> and postpone "balance" until it is needed/wanted

   alex: multiple proposals on flex-direction issue
   glazou: want lines to go start and end,not left and right
   tab: no, sometimes you need left and right
   glazou: you need to take into account text directionality
   <tantek> there are cases for both
   tab: sometimes left and right are all that matters
   alex: does this need to be one property, or can line property be one
         and children direction another
   alex: with one property, it can become verbose
         see option 2
         sometimes want direction to be physical, sometimes mesh writing mode
         direction, it all creates a lot of permutations
   tantek: seems like a similar problems to background position ppp
           different dimensions, and lots permutations…
   fantasai: we don't have keywords for background position yet
   fantasai: they're different keywords
   tantek: we should emulate design pattern of background position
   alex: how would that translate?
   tab: looking at option 1, if we separate the keyword and remove the dash
         (have two keywords), the grammar becomes simpler
   david: we don't want to mix logical and physical
   fantasai: i can see use cases for it
   fantasai: horizontal toolbar at the top of the screen, with logical ordering...
   davidb: the logical ordering could be vertical, you could end up making
           multiline in a way that makes no sense
   david: that means we would want either one property, or four...
   <TabAtkins> [ lr | rl [ tb | bt ]? | [ tb | bt [ lr | rl ]? ] | (duplicated for logical)
   <TabAtkins> [ lr | rl [ tb | bt ]?] | [ tb | bt [ lr | rl ]? ] | (duplicated for logical)
   <tantek> tab did you mean? [ lr | rl [ tb | bt ]?] || [ tb | bt [ lr | rl ]? ]
   alex: is this space separated?
   tab: yes, just like option 1, but with a space instead of -
   davidb: what if the options for logical were simply forward and reverse?
   alex: was the same way for the primary direction
   <tantek> tab, oh wait I see what you're doing
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jun/0303.html
   david: still has confusing situations where. if primary direction is logical
          (line flows ltr) and secondary direction....
   alex: before we had four options for directions
         direction didn't have any physical options
         we could get back to that set of options
         would get us 4 x 2 x 2, 16 options
         the forward direction is always a good default
   fantasai: agree
   <TabAtkins> [ lr | rl | tb | bt | se | es | ba | ab ] [forward | reverse]?
   <tantek> TabAtkins - I like that one
   david: ab and ba are confusing (stand for before and after)
          but could be interpreted as above and below (which the opposite
          of the intend)
   TabAtkins: Instead we could use [inline | inline-reverse | block |
              block-reverse] for the logical directions.
   <dbaron> TabAtkins, yeah
   alex: don't like combining orientation and direction
   glazou: what's the use case? switching from horizontal to vertical?
   alex: horizontal and vertical are common, reverse direction is rare
   tantek: those primary use cases should be documented (with diagrams)
   fantasai: your browser window is a good example
   steve: vertical = horizontal text, vertically stacked?
   <tantek> REQUEST: diagrams in the css3-flexbox editor's draft that illustrate
            the "two primary use cases" (as defined by alexmog)
   fantasai: i like we should be able to say "horizontal" or "vertical" and
             get good defaults
   david: I like tab's new proposal
          you get good horizontal/vertical defaults out of physical direction
   <TabAtkins> [ lr | rl | tb | bt | block | block-reverse | inline |
                inline-reverse ] [ forward | reverse ]?
   david: doesn't give you wrap direction, but perhaps should be second
          keyword on wrap
          (i.e add reverse keyword)
   david: so we could have "balance reverse"
          line-wrapping default would be to use whatever direction you haven't
          used yet
   <TabAtkins> flex-wrap: nowrap | [ wrap reverse? ]
   fantasai: imagine vertical toolbar on the side
   david: don't want lots of possibilities that mean nothing
   fantasai: (draws on whiteboard)
   fantasai: tab's proposal is simple from a design perspective
             but the keywords don't really make sense
   <bradk> I can't see the whiteboard
   <nimbupani> bradk: https://picasaweb.google.com/lh/photo/2rjkIQQ4ns1SRUe9gqNBZ4dZ5C9XFTqVazEUohMLkyU?feat=directlink
   fantasai: If you have a vertical toolbar on the left, you want new lines to
             stack to the right.  But if you have it on the right, you want new
             lines on the left.  This is unrelated to the logical directions.
   whiteboard: toolbar on right that moves toward left, and vice versa
   david: looking at examples, and don't know what they do, e.g.
          "flex-flow: reverse"
   david: why is there an implicit default of inline?
   fantasai: the default is rows
   <glazou> daniel, david and tantek don't understand the meaning of the values
   dbaron: what is ltr ttb?
   alex: like wrap direction part of wrap property
   alex: we just need 4 physical, 2 logical and that's it
   tab: we would need to define validity across two properties...
   david: not sure i buy the use case (from fantasai)
   fantasai: if you have toolbars on the side, they're going to wrap towards
             the center. if you have chinese labels, for example, you would
             still wrap the buttons inward
   fantasai: the layout of the UI would probably trump the text direction
   <tantek> alexmog: I just looked at the 13 examples at
            http://wiki.csswg.org/spec/css3-flexbox/use-cases - which of
            those are the "two primary use-cases" ?
   fantasai: need to find civil engineering software in japanese
             they have the most horrible UI...
   tantek: which of the 13 use cases on the wikipage (see above) are primary?
   dbaron: I think he's talking about 2 primary direction patterns within
           these use cases
   alex: use cases are from Tab and focussing on things that are better w/
         Tab's spec
   tab: not true, they are extensive use cases. the fact they are better is
        not a consequence of me writing them
   tab: i haven't been cherry-picking
   alex: they're not prioritized right now
   alex: simplest use case is horizontal toollbar
   tantek: that's number 5?
   glazou: am i the only finding those examples extremely difficult to read?
   glazou: CSS used to be easy to read
   tab: those examples are *really* difficult to do with CSS today, or require
   tantek: could we order from simplest/most common to more complex
   REQUEST 1: order use cases from simplest/most common to more complex
   REQUEST 2: include some images/graphics illustrating them
   alex: can we narrow down to a couple options we like?
   tab: fantasai has illustrated well that physical and logical orientation
        are independent
   fantasai: although in some cases you *may* want them to be related
   alex: there can be some combinations that don't make sense.
   alex: but I'm not very concerned about this
   could use a dash instead of space
   <dbaron> tb | bt | lr | rl | [ tb | bt ] [ lr | rl ] | [ lr | rl ] [ tb | bt ]
            | [ block | inline ] reverse? reverse-line?
   tab: we traditionally only separate properties when they are useful to be
        cascaded separately, but that's not the case here
        or at least we haven't made that case
   glazou: even if you rotate an interface from landscape to portrait mode?
   steve: suggestion: people who have a scheme in mind apply them to at least
          two use case so we can better understand what the options are
   alex: direction vs. orientation or direction vs. flow-wrap direction, we
         don't want to separate into two properties
         may have a single set of keywords, separated by dashes or spaces
         we'll have diagrams tomorrow and proposal
   <dbaron> tb | bt | lr | rl | [ tb | bt ] [ lr | rl ] | [ lr | rl ] [ tb | bt ]
            | [ block | inline ] wrap? reverse? reverse-line?
   dbaron: also: is wrapping or not part of the same property?
   (see above)
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jul/0406.html
   Alex: we got an action. time for more issue?

   ISSUE 3: flexbox has two ways to align transverse directions — confusing
            and still incomplete
   alex: if we're going to talk about flexbox tomorrow, might be better to
         talk about alignment issue then
   alex: alignment is currently happening by setting margins, only option is
         baseline or nothing
         but two ways to do alignment, which is confusing
   tab: currently happening using margins and padding
   alex: that's another problem: padding is not parent controls
         flexbox is dealing with margin boxes of its children
         some layouts don't have padding at all
         it may still be interesting to stay that padding only applies to
         normal flow, displayed inside blocs
         can't apply it generically
   tab: yes, can't change other models
        we won't redefine what padding means, but padding is still something
        that flexbox can affect on children
   steve: what's the computed value of computing
   tab: the result of resolving the flex
   tantek: it's the used value, not the computed value
   tab: i tried to change this for transverse alignment
        it changed it from keywords because i wanted it to be easier to
        understand wrt the box model, where you use margins and padding
        for alignment
   alex: i would be ok with that if the align property disappeared
   tab: but we really want baseline alignment
   dbaron: using auto to align is really confusing
   tab: i used to think so, but not anymore
   fantasai: can be used to mean different things
   alex: so, get alignment back, but leave margins
         that's what grid-layout does right now
         it has a line property (before, after, stretch)
         if stretch, margin: auto margin-box will stretch to the whole box
   tab: that's weird, though
        old definition of stretch is to stretch the box, not the margins
   alex: flexbox is really dealing with margin boxes
   tab: so you're having alignment to be more powerful than margins
   alex: yeah, that's how it works now
   steve: that's what you have to do to support baseline, right?
   tab: if we make it work this way, i'd like to get flex pack to work the
        same way
   tab: in the alignment direction there's no flexibility at all unless you
        align stretch
        then we try to resolve stretchy height, and if that doesn't take all
        the space then stretchy margins
   alex: we should use the same sequence as for the box model: margin, widths
         use the same order to resolve
   tab: so width and height resolve first
   tab: need to think about it, it might work
        want to make sure we have a consistent resolution, otherwise it's
        going to be very confusing
   steve: in the alignment direction, there is no flex?
   <dbaron> TabAtkins, I'd suggest "main axis/direction" and "cross axis/direction"
   alex: right
   molly: this consistency issue is very important for authors
   tab: i think it might work out. let me play with it a bit more.
        i will come back with a proposal for this tomorrow and we can vote
        on it (or decide it still sucks and talk about it some more)
   glazou: fifteen minutes break
   * fantasai loves dbaron's proposed terminology, let's use it!

   glazou: gavel, gavel, gavel
   and we're back from our fifteen-ish break
   glazou: back to flexbox. alex has the floor
   alex: we'll have a proposal tomorrow to discuss
         regarding ISSUE 4
         consider 'true-center' as an align option for flexbox
         resize text area until it's longer than the green box
         see section "Center stage: positioning in the middle"
   <bradk> link?
   <stearns> http://www.html5rocks.com/en/tutorials/flexbox/quick/#toc-center
   tantek: isn't that what text-align does today?
   alex: doesn't make a lot of sense for text, but useful for images
   steve: related problem with exclusion positioning
          does true-center mean center of container?
   tab: it's the "center of mass"
   fantasai (after checking the FE handbook): "centroid"
   steve: interesting to discuss with irregularly shaped objects
   tab: question is do we want a way to describe it should stay centered
        even if larger than parent container?
   steve: what about scrollbars, then?
   alex: let's keep as an issue until we have a use case identified
   tab: so, not in spec at the moment, until we have a use case
   steve: can we add to the issue that center here means "center of object"
   molly: the relation to overflow is an important one for authors/developers...
   <arronei> old centering proposal from Ian,

   alex: ISSUE 5: page breaking
         flexbox paginates in both direction in IE
   tab: we need to solve it, alex has a proposal based on implementation experience
   steve: if we have a flexbox in a multi-col, does it columnate?
   tab: splitting display into display-inside and display-outside?
   tantek: what are the use cases?
   tab: use case is table cell (or list item) being a flexbox
   tab: ex. gmail, my list of messages is list item, and i want a item number
        in my list item
   tantek: in gmail, it's tabular data, not a list
   fantasai: you need a grid model, so they can align
             you would need a 2D flexbox, which we don't have
   tantek: this example doesn't seem to be a convincing use case
   alex: syntax that defines behavior doesn't match what any reasonable
         implementation is going to do, which is to treat those properties
   alex: there's nothing wrong with having a table-cell treated as a
         flexbox (or a grid)
   alex: if in the future we're going to get more layout types that require
         a particular behavior on child element
   alex: this lack of display-inside will become a blocking problem
   tantek: can we solve it when we have this future use case defined?
   dbaron: we keep adding new display types to work around this...
   steve: the spec is more understandable if there is an internal and external
          behavior defined, which are independent
          understanding the kind of objects we're dealing with is important
          to use it correctly
   tantek: are you saying if we introduce it now it simplifies flexbox?
   tab: yes, because i wouldn't have to introduce a new display-type value
        that still doesn't solve the table-cell issue
   glazou: Do we need 2 properties (display-inside and display-outside) or an
           ::outside pseudo-element?
   tab: it wouldn't work for list-item
   fantasai: you can't an inline list item behavior by nesting any of the boxes
             we have today
   alex: if we make this addition, in what spec would we add it
   Arron: that would be CSS3-box
   anne: there's a version from 2007
   steve: there's a more recent editor's draft; bert has been working on it
   anne: it's out of sync with 2.1, though
   tab: we might want to try to revive box, or get bert to share what he's
        working on...
   tantek: would prefer the latter
   tab: you do want those properties to cascade separately, so two properties
        would make senese
   tantek: do the use case support only one of the two properties?
           are there use cases for both?
   fantasai: imagine a toolbar...
             i can position elements inside it using flexbox, table models
   fantasai: but i only want to touch the outside, each items in it can have its own
             internal structure
   fantasai: but i don't want to affect that
   tab: we do want to independently control both
   dbaron: a lot of CSS uses are not 5 line examples, they're very complicated
   tab: when using scripting, you'll want to be able to read the value and
        restore it
   tantek: but this doesn't resolve display: none
   tab: marker creation or display:noning could be hooked to another property
   tantek: that's the script example i was thinking about it: hiding and
           showing things
   tab: would hate to have something special there if we can do something css-ly
   alex: are we ready to create an action?
   tantek: if you start splitting the display property, you'll need to look
           into display:noning and possibly more, with use cases
           then you can argument whether authors need it or not
           we could split it too far
   tab: i don't think we have to
   <bradk> I agree with tantek
   tantek: agree, but use cases will help us make sure of that, and not just
           use our opinions
   tab: the cases we have today are inside/outside, noning, potentially marker
        (if there's a use case)
   ACTION tab: specify use case that will go as an issue in CSS3-box
   <trackbot> Created ACTION-342
   steve: assuming there are use cases for this, is this an issue we should
   alex: rephrasing: given our current understanding of the issue do we think
         display-inside is a good idea?
   tantek: i don't know
   alex: yes, i think it is a good idea, given our current understanding
   steve: didn't hear people violently opposed to doing it, but would like
          use case justifying doing it and driving its design
   <bradk> Based on what I understand now, I am generally against, as I think
           it adds complexity to authors that they don't need.
   glazou: what about existing keywords, i.e. inline-table
   tab: they would become shorthands
   alex: would there be an issues with current implementation if you used all
         permutations of the two properties
   <bradk> It is reasonable to have display-inside|outside as something used
           in spec language, without exposing it as values to authors.
   Arron: like inline-run-in
   * dbaron wonders if we should also have display:walk-in and display:sit-in
   * sylvaing display:sleep-in ?
   * tantek only if we can also have display:walk-out and display:sit-out

   <tantek> just for kicks - here's a discussion of separating out display
            from 2004:
   <tantek> quoting myself from those minutes:
            "TC: I still want the list-item-ness and none-ness separate." (lol)
   <tantek> aside: 2000 era discussion of split of display property:
   <tantek> (btw we previously (2000) discussed outside/inside as role/model
            e.g. display-role:inline; display-model:block == display:inline-block; )
   <dbaron> yeah, and I proposed renaming them to inside/outside so we could
            remember which was which :-)
   <glazou> tantek: turning archeologist?-)
   <tantek> glazou: those who ignore history (of standards) are doomed to
            repeat (proposals).
   <glazou> tantek: and same mistakes...

   alex: ISSUE 7
   tab: about floats
   tab: spec currently says that floats are ignored and doing what it would do
   fantasai: it would be interesting for the float to be a flexbox item
   tab: what about vertical layout?
   <dbaron> So in vertical layout float:left becomes float:top and float:right
            becomes sink:bottom?
   steve: why doesn't it get wrap in an anonymous block
   steve: so the question is: if i have a float in the middle of the run,
          what should happen?
   fantasai: you should do what we do we tables
   tab: would love that. what do you do with tables?
   dbaron: i would rather not, because nobody likes what we do
   fantasai: We take the entire run of improper table children and wrap it in
             a table cell
   glazout: time-out. many more flexbox issues...
   alex: I propose ignoring 'float' property on flexbox items.
   alex: propose to ignore float on flexbox children
         we already ignore float on absolute positioning
         and if you have something that used to be a float, let's say a
         block-flow placed in a flexbox
         you would expect to see a sequence a flexbox elements, but making
         it a float make it wrapped in an anonymous block, so the sequence
         is going to become a anonymous block
         can't really see useful applications of this, because it only happens
         when you don't have proper element hierarchy
         we're trying to make the fixups scenario somewhat more logical, but
         could create confusion and misinterpreation of intent when there is
         no clear benefit of doing that
   steve: if i have a string of text with a float in it, the flow is usually
          not broken up
   alex: problem is model of flexbox and float are different, and have
         different layout systems
         we have decided to make inline replaced element individual flex
         items because otherwise it creates confusion
   steve: we both giving argument of consistency, in inconsistent ways
   alex: two issues: how to deal with floats, and current definition of fixups
         in flexbox
   dbaron: I could see changing the wrapping rules to group all text and
           anything with display-outside:inline
   TabAtkins: though that raises issues with replaced elements
   <tantek> float is merely a display-role
   <tantek> so you add a new value display-role
   <tantek> and then float value other than none "sets" display-role: to float.
   fantasai: might make sense to have people assign display: block for buttons
   steve: i'm concerned about cut/paste and if things behave completely
          different depending on context
   alex: we can continue discussion on wiki

   alex: two more issues
         ISSUE 10 treating of absolute positioned content
         ISSUE 11 inline element within fixups
   topic: abspos elements directly contained inside a table (e.g. in place
          of a table cell)
   alex: everywhere else, an anonymous empty line is invisible and have no
   alex: here, we are creating a third element in between
   tab: if i did this just for flexbox it would be weird, but tables work
        the same way
   tantek: I think it's a bug
   fantasai: behavior is screwed up, only makes sense to implementor of
             layout engine
   dbaron: i think we should just advise author not to use absolute positioning
   tab: you get an empty table cell
   fantasai: this is interoperably implemented today for tables
   fantasai: but i think it's enough of an edge case that we don't have to be
             consistent with tables, if we can find something better
   <JohnJansen> agree. I don't want to repeat what I think is a mistake simply
                for consistency
   fantasai: what if you have a ghost but it was not allowed to take any size
   tab: even if it doesn't take space, it will allocate extra packing space
        around it
   steve: you really want display: none
   tantek: you could define so that it's infinitely thin and doesn't affect
   fantasai: you still need to define the auto position
   <arronei> table test case:
   tab: flex-pack: justified puts the leftover space between items, so the
                   extra space caused by the ghost will be visible
   alex: i would prefer not having a (detectable) ghost altogether
   <tantek> ghosts should not be detectable
   tab: i remember how difficult it was for me to define it for table, until
        everyone did the interoperable weird behavior
   alex: let's not just create the ghost
   <tantek> sounds good - no ghosts
   dbaron: alt proposal: ignore absolute positioning
   our flexbox implementation has ignored floats and absolute positioning
   dbaron: it's a display-outside value
   fantasai: it should have been and effectively is a display-outside value
   alex: can't think of a meaningful scenario where you do what's on ISSUE 10

   anne: if we do display-outside, would it have values like position and float?
   fantasai: display, as a shorthand, would have to reset display-outside
   tantek: maybe it's not a shorthand?
   fantasai: how would you make it not a shorthand?
   tantek: proposal to ignore abs pos, based on implementations
           if you want abs pos to mean something, provide use cases
   tab: i can find use cases
   ACTION tab: provide use cases illustrating value of abs case in context of ISSUE 10
   <trackbot> Created ACTION-343

   Alex: ISSUE 11
   glazou: the idea of foo generating anonymous box scares me
           an anonymous block gets created around the <span>
   dbaron: It could also just be seen as depending on whether your anonymous
           box construction algorithm operates top-down or bottom-up?
   dbaron: I think they're boxes, and you should define the anonymous box
           construction algo so that it gives you the result you want
   dbaron: i don't think it's defined already, but it could be defined
   <dbaron> (run that by Boris Zbarsky, though...)
   tab: it operates on box tree but happens before the block in inline fixup

glazou: stop
fantasai: we had action item to invite anton to WG. What happened?
glazou: I think Bert was supposed to invite him.
fantasai: would be good to have him editing CSS3-box
ACTION glazou: check on the invitation of Anton to WG
<trackbot> Created ACTION-344


ScribeNick: fantasai

   glazou: So who reviewed HTML5?
   Tantek: Define "review".
   dbaron: I reviewed some of the pseudo-class stuff, but not in the last
           6 months.
   Anne: ... and the rendering section
   Tab: I looked at it
   dbaron: Every time I look at it, I feel it's not complete.
   discussion between glazou and anne wrt group comment vs individual comment
   glazou: We have to reply because the HTML5 spec defines things that are
           in the CSS scope.
   SteveZ: If we're letting them define what CSS says and we don't say anything
           about it
   dbaron: The pseudo-class stuff and rendering section don't define CSS
   glazou: I sent a note to ? saying that we were not pinged about the
           additions to selectors.
   glazou: CSSWG was not consulted about this.
   dbaron: Selectors says what :optional means, and HTML5 says when things
           are optional.
   Tantek: That's the correct split, if needed we should fix our spec to make
           that work. If HTML5 oversteps its definition, then that's a problem
           they need to fix
   dbaron: What was there other than :ltr/:rtl that the HTML WG shouldn't have
   anne lists some stuff
   ?: also some extensions in WebVTT:  ::cue, :past, :future
   glazou: Even if the split between the specs is valid, the lack of
           communication between CSSWG and HTMLWG is an issue.
   Tantek: It's a process issue.
   glazou: Yes, but in the end it has technical implications.

   discussion about coordination and communication
   Tantek: I'm going to make some statmeents
   Tantek: This group is about advancing the Web platform.
   Tantek: We have a lot of the same goals and design principles.
   Tantek: We should communicate that we are receptive to ideas and feedback
           that fall under our scope.
   Tantek: That's the best way to encourage that communication.
   Tantek: Good ideas happen everywhere. If we communicate that, we're more
           likely to get that feedback.
   Florian: I agree. Even if as a group we are offended, acting that way will
            not improve the situation .
   Steve: .. We should take a positive approach towards improving communication.
   Steve: We should document what the split is. And request that when they
          want something on our side, they make that request.
   glazou: Does everyone agree with that?
   <dbaron> http://dev.w3.org/html5/spec/rendering.html#timed-text-tracks-0 says
            "Note: This section is intended to be moved to its own CSS module
             once an editor is found to run with it."

   glazou: I suggest that I don't write this comment
   Anne: HTMLWG is less of a centralized effort than CSSWG. It's hard to get
         a coordinated response.
   glazou: Still have a few technical issues to discuss.
   glazou: Wrt disabled attribute on style sheets -- it's not reflected in
           the markup.
   glazou: Makes it impossible to save the disabled status on the <link>
   dbaron: How does that interact with fantasai's proposal of the interaction
           of alternate style sets from 4-7 years ago?
   fantasai: I think hixie wrote a variation on that that was in one of his
             whatwg specs, which bz implemented.
   anne: It's in WebKit and Gecko and in cssom
   Tantek: Is there a bug report on this?
   anne: Wasn't it wontfixed?

   glazou: There's also ::cue, :past and :future pseudo-classes
   dbaron: So that section has a note at the top saying that this section
           should move to a CSS spec once an editor is found
   fantasai: But they haven't told us that.
   anne: Those definitions are very specific to how WebVTT works
   fantasai: :past and :future should apply to other formats as well
   fantasai: e.g. reader

   glazou: Last comment I have is that HTML5 makes a lot of references to CSS
           editor's drafts and WDs, and says these references are normative
   glazou: I think it's a problem to normatively reference a CSS editor's draft.
   anne: They exist, you can reference them.
   glazou: They're unstable.
   sylvain: They're not normative.
   glazou: In the Consortium you cannot reference such a document.
   glazou: That's why some of our documents were blocked in the process.
   sylvain: If HTML5 wants to depend on something that prevents them from
            advancing, that's their problem
   Molly: But if people depend on something that's unstable and it changes,
          that's a problem for everyone.
   sylvain: So we have the issue. We have to call it out.

   * tantek created http://wiki.csswg.org/spec/reviews/html5

   <TabAtkins> Regarding the :ltr/:rtl thing, it was added in response to
                <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10808>, filed
                by the i18n WG.

<br type="lunch"/>
Received on Saturday, 30 July 2011 00:18:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT