- From: timeless <timeless@gmail.com>
- Date: Tue, 2 Jun 2015 07:56:31 -0400
- To: Florian Rivoal <florian@rivoal.net>
- Cc: www-style list <www-style@w3.org>
http://www.w3.org/TR/css3-ui/ Florian Rivoal wrote: >> timeless wrote: >> 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? >>> The user agent must allow the user to resize the element with no other constraints than what is imposed by min-width, max-width, min-height, and max-height. >>> (The "must" is at risk since only Firefox currently supports this, and may be downgraded to a "should"). >> (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. 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` ? ... 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. >>> 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: > https://en.wiktionary.org/wiki/ellipse#Verb No, actually. In that case, the words were omitted, the ellipsis were not inserted: >>> In B's response to A's question:- (A: Would you like to go out?, B: I'd love to), the words that are ellipsed are go out. > 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. >>> 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`... > 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. >>> 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, and IMO too weak. > 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. My comment here is also an anchor for someone from WCAG or somewhere to comment. >>> 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 > http://dev.w3.org/csswg/css-cascade/#initial-values Yes, I know the meaning of Initial. I was just anchoring the comment there for lack of a better anchor. > UA styles are a separate matter. The other place which you offered to accept w/ CSS WG agreement is probably better. >>> 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.
Received on Tuesday, 2 June 2015 11:57:04 UTC