Florian Rivoal | 6 Feb 06:28 2016

[css-ui-4] -webkit-user-select


css-ui-4 specifies the user-select property. This property is widely used under its webkit prefixes,
which is causing enough issues that both Edge (not IE11) and firefox (in nightlies) have decided to
support it under the webkit prefix in addition to their own.

I would like to encourage browsers (webkit and blink included) to start supporting the unprefixed syntax
as well, rather than just their own prefix plus the webkit prefix.

That said if browsers are finding it necessary to support the webkit syntax (which does not surprise me), we
should spec it as well.

Similarly to what we agreed to do for work-break:break-word, I propose adding a compatibility appendix to
CSS-UI-4 defining how -webkit-user-select maps to user-select, while making it clear that this is not
what authors should be using.

 - Florian

fantasai | 6 Feb 03:39 2016

[mediaqueries] light-level

# For accessibility purposes, user agents may offer manual
# controls allowing the user to switch between the 3 levels
# of independently of the ambient light level, as high
# contrast or low contrast styles may be more suitable for
# users with visual disabilities.
# Using this media feature for accessibility purposes
# overlaps a lot with the high-contrast media feature
# proposed by Microsoft. Can we adjust this so that it
# covers all use cases for both, or somehow modify them
# to work in an orthogonal, rather than overlapping, fashion?

So, I don't think we should mix up accessibility and light-level.
Responses to light-level can involve contrast but also background/
foreground swaps: e.g. I might go with a light-on-dark scheme in
dim lighting to avoid disrupting low-light vision, but not
necessarily reduce the contrast.

If we want to present contrast preferences, that should be
explicit. We can show examples where someone who is drawing
up a low-contrast scheme for dim lighting *also* applies that
for people with a contrast preference, but they shouldn't be
tied together.

So I'd remove this issue and work on addressing the need for
contrast or foreground/background preferences.


(Continue reading)

fantasai | 6 Feb 03:39 2016

[mediaqueries] status and moving forward

Overall, the spec looks really good. I think we should take a cut of
it and ship Level 4 with everything that we're sure is stable, since
I think that's probably a lot of it. I just raised a few issues, but
they should be straightforward to solve imho, being mostly syntactic.
I say let's solve those, fill out 2.5. Combining Media Features, and
publish an LCWD.

Stuff I vaguely remember (or are noted in the draft) as not being
100% sorted as to whether they're the right approach:
   - light-level
   - inverted-colors
   - custom MQ

These I think should be deferred to Level 4 so as not to hold up the
rest of the features, some of which are desperately needed (like
pointer and hover). And of course we should continue to actively
work on them, and fold in the prefer-* stuff that's quite closely
related, use case wise, to the first two.



fantasai | 5 Feb 19:20 2016

[mediaqueries] update-frequency naming

# update-frequency: none | slow | normal

Given this would be particularly useful in boolean context,
I'd like to suggest renaming it to just "update".

I might also suggest renaming "normal" to "fast" since it's
easier to remember "slow/fast" as a pair.


fantasai | 5 Feb 19:25 2016

[mediaqueries] overflow-block/inline

While I'm sympathetic to the differences between block and inline overflow,
and it may indeed be necessary sometimes to query them independently,
I think it's probably easier for authors if we provide a simple 'overflow'

overflow: none | scroll | scroll-page | page

where the author assumption is that if it's 'page', then there's no
inline scrolling, although the UA may allow it.

Also, I suggest the following renamings:
  paged -> page for grammatic consistency with scroll
  optional-paged -> scroll-page because it does both, it's not just paging


fantasai | 5 Feb 20:08 2016

[mediaqueries] Editorial

1. Note in the range syntax that it is new to L4, and thus less widely-supported
    than the min-/max- prefixed syntax.

2. This sentence is weird:
  # In addition to conforming to the syntax, each media query needs to use media
  # types and media features according to their respective specification in order
  # to be considered conforming.
If you're trying to say that such a syntax would be invalid, maybe

3. Start a new section "Evaluating Media Queries" or somesuch, starting here:
  # Each of the major terms of <media-condition> or <media-condition-without-or>
  # is associated with a boolean result, as follows: (...)
Put this section after 3.1 Error Handling.

4. Use curly quotes instead of straight quotes in prose (not code).

5. "the style sheet is usable on printed output" -> s/usable/used/
    likewise for subsequent examples

6. “A specified <length> cannot be negative.” ->
    “Negative <length> values are invalid.”

7. We generally don't define types in the "Values" section in the introduction:
    that section is just saying where to find definitions for types not defined
    in this specification. (It is defining module interactions.) If you're
    defining a type in a spec, put it somewhere more appropriate to the main
    content of the spec.

8. “<resolution> does not refer to the number of device pixels per physical
    length unit, but the number of device pixels per css pixels.”
(Continue reading)

fantasai | 5 Feb 19:56 2016

[mediaqueries] hover: on-demand

hover: none | on-demand | hover

Unless we can make 'on-demand' result in a boolean evaluation of "false",
I think we should drop the value and classify such UAs as "hover: none".
It seems like these UAs should be opted into  <at> media not (hover) designs
rather than  <at> media (hover) designs.

We can note that :hover and hover events *can* trigger on such devices,
but nothing in the page should be designed for that mode of interaction.


fantasai | 5 Feb 20:03 2016

[mediaqueries] scripting

# scripting:
#   enabled
#     Indicates that the user agent supports scripting of the page and
#     that support is active for the current document.
#   initial-only
#     Indicates that scripting is enabled during the initial page load,
#     but is not supported afterwards. Examples are printed pages, or
#     pre-rendering network proxies that render a page on a server and
#     send a nearly-static version of the page to the user.
#   none
#     Indicates that the user agent will not run scripts for this document;
#     either it doesn’t support a scripting language, or the support isn’t
#     active for the current document.

I'm wondering if what you actually mean here is more like

scripting: none | onload | interact


Or does 'initial-only' not fire onload events, either?


James Craig | 5 Feb 11:11 2016

[selectors] Reference Combinators removed?

The Reference Combinator was removed from the CSS4 selectors draft citing "lack of interest."

Yes, all this can be done with JavaScript, but if one of the goals of CSS is reduction of reliance on
scripting, the interest could remain.

For example:

/* CSS-only highlight of the Maps POI pin when hovering over a sidebar details list, and vice versa */
.pin:hover /data-sidebaritem/ .sidebaritem  { /* highlight styles */ }
.sidebaritem:hover /data-pin/ .pin { /* highlight styles */ }

It looked like it would have also been especially useful for ARIA, which leverages IDREFs. 

/* display the tab panel whose controlling tab is selected */
.tab[aria-selected="true"] /aria-controls/ .tabpanel { display: block; }

/* highlight the current autocomplete suggestion for a custom combobox */
input /aria-activedescendant/ li { background: yellow; }

Florian Rivoal | 4 Feb 10:21 2016

[css-containment] layout containment and overflow

Because an absolutely positioned elements sticking out of a layout-contained element may cause a
scrollbar to appear on a containing element, there can still be layout changes out of the containing
element, and that's an issue (tracked as issue 2 in the spec).

As suggested by the spec, one way out of this is for layout containment to imply paint containment as well,
but there's an less heavy handed alternative. We could add one entry to the "Giving an element layout
containment has the following effects:" list:

* If the computed value of the 'overflow-x' and 'overflow-y' properties of the containing element is
''visible'', any overflow out of the containing element is treated as ink overflow.

- Florian

Myles C. Maxfield | 4 Feb 09:52 2016

[Font Loading] FontFace's Attributes

[Sorry, sent with correct subject this time]

I'm implementing the CSS Font Loading spec in WebKit. During the implementation, I have come across this
issue in the spec:

When FontFaces are added to the Document's FontFaceSet, a layout may occur at any time which triggers these
FontFaces to be load()ed. This layout uses the FontFace's attributes (family, weight, etc.) to discover
which FontFaces need to be load()ed. However, during the load, script may change attributes of these
FontFaces so that they no longer match what the layout requires. Instead, modifying FontFace's
DOMString attributes should be a no-op (possibly additionally throwing an exception) after the
FontFace has been load()ed.