- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 29 Jul 2011 17:17:38 -0700
- To: "www-style@w3.org" <www-style@w3.org>
IVS Feedback
------------
- RESOLVED: Send fantasai's draft as official comment from CSSWG on Unicode PRI184
http://lists.w3.org/Archives/Public/www-style/2011Jul/0518.html
Flexbox
-------
- 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
proposal.
- Discussed block-in-inline splits within a flexbox and implications of the box
generation model.
HTML5 LC
--------
- 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:
http://wiki.csswg.org/spec/reviews/html5
====== Full minutes below ======
Present:
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
Agenda
------
Let's talk about the agenda… Looking at the wiki
http://wiki.csswg.org/planning/seattle-2011
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
http://lists.w3.org/Archives/Public/www-style/2011Jul/0518.html
Flexbox
-------
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
JavaScript
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?
http://www.html5rocks.com/en/tutorials/flexbox/quick/
<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,
http://lists.w3.org/Archives/Member/w3c-css-wg/2002JulSep/0296.html
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
separately
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
etc...
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
pursue?
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:
http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0311.html
<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:
http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0353.html
<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
otherwise
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
effect
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
layout
fantasai: you still need to define the auto position
<arronei> table test case:
http://test.csswg.org/suites/css2.1/20110323/html4/table-visual-layout-023.htm
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
HTML5 LC
--------
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
done?
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 UTC