W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-ui] Updated WD of CSS-UI L3

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 2 Jun 2015 00:09:21 +0200
Cc: www-style list <www-style@w3.org>
Message-Id: <9013B0AA-439A-4E25-BE1C-860D3EE8FAE6@rivoal.net>
To: timeless <timeless@gmail.com>

> On 01 Jun 2015, at 22:17, timeless <timeless@gmail.com> wrote:
> http://www.w3.org/TR/css3-ui/


Thanks for the review and feedback.

>> The following features are at-risk, and may be dropped during the CR period:
> Is it worth calling out other at-risk pieces, like the resize: must?

resize doesn't have a 'must' value, and none of the values of resize
are at risk. What do you mean?

> (and the ellipsis: string)

"text-overflow: string" is called out as being at risk at the top of
the document, and not in the main text.

I am not sure what you are suggesting.

>> ellipsed
> Android has:
>> getEllipsizedText
> I'm familiar w/ ellipsized, I don't think there's any particular
> reason to use "ellipsed" instead (the "dictionaries" for "ellipsed"
> just say past tense of ellipse which makes no sense).

Dictionaries I've checked don't have ellipsize, and the first google
hit for "ellipsized" is "What does ellipsize mean in android?"

Merriam-Webster doesn't have "to ellipse" as a verb either, but
wikitionary does, with the meaning we want:

Even if it is a rare word, I think we're fine.

>> 4.4. outline-color property
>> The outline-color property accepts all colors, as well as the keyword invert. Invert is expected to perform a color inversion on the pixels on the screen. This is a common trick to ensure the focus border is visible, regardless of color background.
>> Conformant UAs may ignore the invert value on platforms that do not support color inversion of the pixels on the screen.
>> If the UA does not support the invert value then it must reject that value at parse-time, and the initial value of the outline-color property is the currentColor [CSS3COLOR] keyword.
> This definition of behavior doesn't really match what OS X does.
> A picture of what it does is included here:
> http://tjvantoll.com/2013/01/28/stop-messing-with-the-browsers-default-focus-outline/

The outline in webkit and Blink does look somewhat peculiar, but this is triggered through
"outline-style:auto". According to the spec:

The auto value permits the user agent to render a custom outline style, typically a style which is either a user interface default for the platform, or perhaps a style that is richer than can be described in detail in CSS, e.g. a rounded edge outline with semi-translucent outer pixels that appears to glow. As such, this specification does not define how the outline-color is incorporated or used (if at all) when rendering auto style outlines.

This is intended to allow the behavior you see.

Firefox seems a bit stranger here, as it does not seem to reliably
support "outline-style:auto", even though it does show a native outline
around focused elements. It do not consider it a conforming implementation.

>> Note: Since the outline does not affect formatting (i.e., no space is left for it in the box model), it may well overlap other elements on the page.
> Please consider adding a note "for accessibility purposes, just
> turning off or otherwise messing with this property is likely to
> result in an application which isn't accessible and will result in
> accessibility people threatening you (and governments refusing to buy
> your products)"
> https://www.section508.gov/

We already have this a bit higher up in the spec:

  "Keyboard users depend on outline on elements in the
   :focus state for interaction with the page, thus authors
   must not make the outline invisible on such elements without
   making sure an alternative highlighting mechanism is provided."

It's not quite as threatening as your suggestion, but it does
make it a spec violation (which validators should call out) for
authors to disable it when they shouldn't.

I am not sure it is the place for this specification to comment
on what third parties might do to you if you do violate the spec.

>> 5.1. resize property
>> Initial: none
> I'm not sure if it's worth noting that UA styles may have other values
> for specific nodes (e.g. iframes or textareas),...

"Initial" has a very specific meaning, see 

UA styles are a separate matter.

>> Selecting the ellipsis should select the ellipsed text. If all of the ellipsed text is selected, UAs should show selection of the ellipsis.
> Firefox 38.0.1 doesn't do this.
> Using the example (rendered):
> <div class="crawlbar">
> CSS is awesome, especially when you can scroll
> to see extra text instead of just
> having it overlap other text by default.
> </div>
> tripple tap on the text (OS X), the entire line selects, and when
> copied, the entire text is copied, but the ellipsis isn't copied. I'm
> not sure how many implementations you think support this, but please
> don't count Firefox as one of them

I assume you meant "[...] but the ellipsis isn't selected".
I agree that Firefox does not implement this correctly, and
neither does it correctly implement "Selecting the ellipsis
should select the ellipsed text".

We don't consider any implementation as correctly implementing
part of a specification until it passes a test suite that covers
that part, so firefox will not be miscounted.

At the same time, note that the sentence you quoted uses "should"
not "must", which means we recommend that browsers do it, but
we do not strictly require it.

>> Some information on these formats can be found on wikipedia.
> Wikipedia is a proper noun.


>> image cursors
>> general purpose cursors
> could these section headings be styled somehow?


>> auto
>> User agents should use currentColor. User agents may automatically adjust the color of caret to ensure good visibility and contrast with the surrounding content, possibly based on the currentColor, background, shadows, etc.
>> <color>
>> the insertion caret is colored with the specified color.
> the => The ??


>> List of substantial changes
>> box-sizing effects on CSS 2.1 width and height computations specified much more explicitly.
>> cursor image formats normatively required
>> caret-color is inherited and animatable
>> New informative appendix on Considerations for Security and Privacy
> Only the first of these has a period....

Fixed, Although that will be replaced before next publication.

>> Appendix D. Default style sheet additions for HTML
>> textarea
>> {
>> /* white space handling of TEXTAREA tags in particular */
>> white-space:pre-wrap;
>> }
> This should also have: resize: both
> Most browsers seem to have moved to this.

This seems like a reasonable suggestion. I'll add this to the spec
if the CSSWG agrees.

 - Florian
Received on Monday, 1 June 2015 22:09:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC