fantasai | 27 Aug 03:07 2015

[selectors] Validity of pseudo-elements per context

We don't define anywhere what pseudo-elements the DOM methods accepting
a selector are allowed to use.

For example, IIRC they can only return elements, so any selectors that
use most pseudo-elements should be invalid. E.g. ::selection, ::before,
::first-letter, etc. should all be invalid.

However, we might want that using ::shadow or ::content as a combinator
is valid, so that
is either invalid or returns nothing but
   ::shadow div
is valid and returns <div> descendants of any shadow trees.

I think this should be done by DOM specifying what it accepts rather
than Selectors defining what DOM should accept. So

1. We need to decide whether .query("::shadow") is throws SyntaxError
    or returns nothing.

2. We need edits saying that the various DOM methods support all selectors
    in the Selectors 4 module plus the selectors in the CSS Scoping Module
    (or not), and nothing that no other pseudo-elements (e.g. those in
    Selectors 3) are valid. Probably this text should go in DOM, but could
    go into Selectors 4 (+ CSS Scoping) if necessary.


Mats Palmgren | 26 Aug 19:57 2015

[css-grid] "Implied Minimum Size of Grid Items" for min-width:auto when 'overflow' is not 'visible'
doesn't specify what happens for min-width:auto when 'overflow'
is not 'visible'.

Flexbox says:
"Otherwise, this keyword computes to 0 (unless otherwise defined by a 
future specification)."

I assume Grid should say the same.

BTW, the "(unless otherwise defined by a future specification)" seems
a bit redundant to me.  I mean, any spec text in any specification
might be overridden by a future specification, right?  So I'm not
sure what the editor is trying to convey by calling that out here.


Stephen Zilles | 26 Aug 12:32 2015

Comments on Section 1 of the CSS Inline Spec

I did a quick review of Section 1 of the CSS Inline Specification some time ago, but as it is on the agenda for this F2F, I took a better look recently.


The things that immediately strike me are:

1.      There is no explicit way to set the alignment point for an object, especially a non-textual object, that is being aligned. This was the role of the “alignment-point” property in the prior proposal. This allows a relevant alignment point to be defined for a image that contains a glyph. Without this replaced elements are always aligned to their bottom margin edge. The “length” value of the “baseline-shift” longhand may help here, but the “percentage”values do not because they are relative to line-height which makes them useless for accurate postioning. If there is an “alignment-point” property (to be able to set it explicitly relative to the object being align (not relative to its parent)), then an “auto” value would mean set the alignment point to the position of the baseline to which you are aligning (in the object being aligned). A length or percentage value would set the alignment point relative to the bottom (content are, padding, margin?) of the object. In both cases, the alignment would be to place the alignment point at the position of the “alignment-baseline” in the parent.


2.      This spec seems to be missing the “inherit” value of the 2.1 “vertical-align” property

In CSS 2.1 the syntax is
baseline | sub | super | top | text-top | middle | bottom | text-bottom | <percentage> | <length> | inherit

In the Inline Module the syntax (expanding the two “longhands”) is

[<length> | <percentage> | sub | super] || [baseline | text-bottom | alphabetic | middle | central | mathematical | text-top |bottom | center | top]


3.      This new syntax allows the specification of both a baseline alignment and the specification of a shift. I presume, but the spec is not clear about this, that the baseline alignment is done first and the shift is done subsequent to that alignment. The spec should make this clear.


4.      Why are “percentage” values of “baseline-shift” relative to the line height? It would seem that font-size would be more relevant. Font size is what is used to scale the baseline pos


5.      With respect to Issue 3. It is clear that these alignments are not baseline alignments, but they were historically part of “vertical-align”. It would seem to make sense for these three values (and an additional “auto” value) to be the values of a third shorthand, “subtree-alignment”. The “auto” value would be the default and would mean use the “alignment-baseline” value. In this case the syntax would become
“[[<length> | <percentage> | sub | super] || [baseline | text-bottom | alphabetic | middle | central | mathematical | text-top]] && [bottom | center | top]

This, however, would remove applying a “baseline-shift” to a “center”ed sub-tree. Is that something that is needed? Currently, shifts cannot be applied to sub-trees that are top or bottom positioned.


6.      This section needs to define how the Line Box is content area is calculated if this module is to replace CSS2.1. Specifically it needs to show how “top” and “bottom” positioned sub-trees interact in determining the height of the Line Box.


7.      This section also needs to specify how the baseline positions in the parent, the scaled baseline table, are calculated using “font-size” (of the parent) and the baseline table associated with the dominant baseline. These are the points to which the child alignment point can be aligned.


8.      XSL-FO has a “use-script” value for “alignment-baseline” to provide a better version of “auto” making the default alignment baseline be script based. This may be a future version feature due to the difficulty of specifying what default baseline each script should use but it  could be useful for authors.


Steve Z

Bo J Campbell | 26 Aug 01:51 2015


I am returning to Flexbox Order in regard to accessibility, usability and the limitation of functionality by forcing a change of DOM to change the focus order.
The suggestion is to create an attribute that states whether the tab order of Flexboxes should follow the visual order or the original logical order after they are reordered. 
In regard to accessibility, WCAG is currently overly specific and outdated in regard to a meaningful sequence of content. Developers need the ability to reorder content and not risk creating accessibility issues by having the focus jump all over the screen. Flexbox is incredibly powerful but extremely risky when it comes to accessibility. An attribute that could keep a tab order the same as the visual order will allow developers to use Flexbox and make individual accessibility judgments on the interactions.
But this is not just an accessibility solution. For instance, consider a row of buttons that can be rearranged by the user. When Flexbox is used to display the new button order, the tab will jump in a non-linear fashion. WCAG does not specifically judge this as a violation, yet tabbing across buttons with the focus jumping back and forth is a very bad experience for any user, especially those with cognitive disabilities and/or using a keboard. 
One may suggest coding alternatives to any example, but a Flexbox attribute solves the issues for usability as well as accessibility no matter how creative a developer gets with it.
Bo Campbell

Koji Ishii | 25 Aug 15:59 2015

[css-text] white-space: pre-wrap

I was re-reading NY F2F minutes[1] on the topic and came up with a few questions. Clarifications appreciated.

1. There's a resolution saying:
  RESOLVED: pre-wrap preserves all spaces visibly and allows
            wrapping before and after every space (to go into level
            3 and mark as at risk)
but this is not in the ED yet, am I correct? I remember I saw some PR from Florian (thank you for that) and would like to confirm this isn't done yet.

2. The resolved behavior would give you a bit strange experience if a word ends at the right margin, then you'd see the space character on the beginning of the next line. Are we sure we want this behavior?

3. I saw the discussion saying:
  Similar to Word behavior.
  So IE probably has the best behavior but isn't spec compliant.
  We should fix it.
but Word does not wrap at spaces, it just overflows to the right margin, so the same as Chrome/Safari.

4. In IE, as far as I looked at it, repetitive space characters cause wrap, but not by allowing break before and after space characters. It looks like "word + one or more spaces" is treated as unbreakable. The resolution above looks like different from IE, different from Word, and different from any other implementations.

An old bug in Chromium[2] got my attention recently, but the resolution does not look to give the desired behavior to me. Could someone clarify?


Xidorn Quan | 25 Aug 14:59 2015

[css-ruby] Add "text-orientation: upright" for bopomofo annotation


I propose that we should add "text-orientation: upright" to the
"rt:lang(zh-TW)" rule.

The reason is that, all the tone marks in bopomofo (U+02CA, U+02C7,
U+02CB, U+02D9) have Vertical_Orientation property "R" while the
bopomofo characters are all "U". It means, without explicitly setting
text-orientation to upright, the text run would break between them,
which makes it impossible to use font feature to place the tone mark

- Xidorn

Koji Ishii | 25 Aug 08:22 2015

[css-writing-modes] caption-side logical values should only be in css-logical-props?

Writing Modes spec defining logical values only for this property does not look consistent.

It's already defined in CSS Logical Properties Level 1[1], so I think we should define only interpretation of existing values in Writing Modes spec, and delegate all logical values to CSS Logical Properties spec.

Does this look reasonable?


fantasai | 25 Aug 00:48 2015

[css-flexbox] Intrinsic Cross Size Definition Totally Wrong

  # The min-content cross size and max-content cross size
  # of a flex container are the cross size of the flex
  # container after performing layout into the given
  # available main-axis space and infinite available
  # cross-axis space.

This might be correct if the cross-axis is the block axis
(I'm not entirely sure), but it's completely wrong if the
cross-axis is the inline axis.


Yifán Wáng | 23 Aug 07:42 2015

[css-counter-styles] armenian typo

The upper-armenian definition in section 6.1 contains a line says:

  system: extends armeniam;

but I suspect it should be:

  system: extends armenian;

with the last **n** instead of **m**.

Wang Yifan

Ed | 24 Aug 05:14 2015

position:sticky-x or position:fixed-x

I think it's worth revisiting position:sticky now that it's seen a few implementations.  The graphics speedup by not using a javascript event is indeed significant.  At least in Safari it works very well for things like sticky headers.

Going back to Mr. O'conners & Maciej comments in 2012 one of the first reasons sticky was proposed, and indeed perhaps the most convincing use case is headers on very long tables.  Unfortunately without a good way to isolate axes row headers in tables don't stick in very wide tables with left-right scrolling.

This type of scrolling based on Javascript and scroll events is possible (e.g. ) but even with small data sets the lag of the headers is awful.  With large data sets, for example a reservation application with 300 rows (rooms) and 700 columns (calendar days for a couple of years) the table headers can easily misalign with data during scrolling.  However maintaining graphics acceleration using position:sticky (at least on the column headers) the table scrolls smoothly, quickly and exactly aligned to its sticky headers, even with larger data sets.

The obvious solution is to isolate axes a la position:sticky-x or position:sticky-y or for both position:sticky, this would give the designer all the tools to build large accelerated tables with very useful sticky headers.  There is some precedent for separating the axes in css properties, for example background-repeat: repeat-y; 

Given that there's been some resistance to implementing sticky, another option would be to allow position:fixed-x or position:fixed-y.  This has the advantage of not clobbering webkit's simple sticky implementation and would still allow for graphics accelerated scrolling with of large tables with apparently sticky headers on both axes.  Javascript and scroll events could still be used for dynamic layout and while the css position state would still lag with the event system as soon as the position changed to either fixed-x or fixed-y graphics acceleration would be possible.  Moreover this would be useful even without dynamic layout and is not mutually exclusive with :sticky.

There are many useful cases for position:sticky and we can't ignore the vast improvement in speed and behavior we get by excluding the event model but until now there's no implementation that accounts for the oldest and most important use case, which is not a design element or a navigation aid but the simple labeling of table data in large scrolling datasets.
Richard Ishida | 24 Aug 12:49 2015

[css-ruby] bopomofo example

attached is a nicer looking example of bopomofo annotation to replace 
the jagged image in the spec (currently fig. 11). Shrink to the size you 

also, just in case it's useful some time, i added a version with pinyin too.