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

> On 02 Jun 2015, at 13:56, timeless <timeless@gmail.com> wrote:
> 
> could you make:
>>>> text-overflow property value: <string>
>>>> text-overflow property 2-value syntax and definition
> ... link to the relevant sections instead of the generic `text-overflow` ?

I think the relevant section is the part where we define the syntax of
text-overflow, since that is where these things may be removed from
if we end up dropping them. Since that appears at the beginning of
the section we are linking to, I would say it is fine as it is.

> ... and could you include the word "ellipsis" in that part of the
> intro, because while it's technically correct, it isn't discoverable
> w/o reading through the whole section.

The 'ellipsis' value itself isn't at risk, so it shouldn't be mentioned
as being at risk. If you meant to include it as part of a brief explanation
of what the property is for, I am not in favor of doing that, as that section
is essentially meant to be an index, not a self sufficient description
of these features.

I've recorded the issue and will bring to the CSSWG.

>>> 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[...]
>> 
>> 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.
> 
> Only if it has the right meaning, which I claim it doesn't.

The issue is recorded, I'll get the opinion of the broader CSSWG
which includes native english speakers (I am not one).

>>>> 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.
> 
> Ah, I missed (and suspect others would miss) that last sentence. It's
> buried in the text for `outline-style`, but I was reading the text for
> `outline-color`. I'd request that you add a sentence to
> `outline-color` noting that its value may be ignored if
> `outline-style` is `auto`...

Informative note are useful, but the sentence you say is "buried in
the text for outline-style" is just two sentences earlier than the text you
quoted, in the previous paragraph.

I am not convinced repeating ourselves so much would help with readability.

I've recorded the issue and will bring to the CSSWG.

>> 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.
> 
> I'm not representing any implementers :), I suppose they might welcome
> bug reports.

It seems to be a known issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1033348
https://bugzilla.mozilla.org/show_bug.cgi?id=1031664
https://bugzilla.mozilla.org/show_bug.cgi?id=1031662

>>>> 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."
> 
> Yes, I saw that (I read the spec...), it's too far away

It is an important requirement, and we don't want to miss it. I've
made if stand out visually (you can check on the Editor Draft here:
http://dev.w3.org/csswg/css-ui/#outline-props).


> and IMO too weak.

I am completely in favor of making strong statements in favor of
accessibility. It is important. However, the current statement:
 - says why doing it would be bad
 - uses "must not", which is the strongest statement that
   we can normatively make

If you think that "Keyboard users depend on outline on elements [...]"
is insufficiently clear or strong, I'm ok with strengthening that part.
Maybe something like:

  "Keyboard users, which includes people with disabilities who may
  not be able to interact with the page in any other fashion,
  depend on the outline  being visible on elements in the :focus state,
  thus authors must not make the outline invisible on such elements without
  making sure an alternative highlighting mechanism is provided."

If you have a suggestion on how to make it even clearer why removing
focus outlines is bad for accessibility, that would be great.

However, I do not think it is appropriate for a specification to 
include "or else..." phrasing describing how failing to conform
may affect your business relationship with third parties who 
care about this requirement.

>>>> Selecting the ellipsis should select the ellipsed text. If all of the ellipsed text is selected, UAs should show selection of the ellipsis.
>> 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".
>> 
>> 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.
> 
> Sure. I only noted it because I noticed while reviewing the spec.

It's a good observation, and we should make sure we write TCs to
cover this case. If you have the time to write one (or a few), I'd
be happy to review it/them and include them in the official test suite.
If not, someone else should eventually get to it, but it could take a
while.

 - Florian

Received on Tuesday, 2 June 2015 13:05:38 UTC