Re: [css-pseudo] please make sure pseudo-element "alt" property makes it into next ED

On 11/5/14, 8:48 AM, "fantasai" <fantasai.lists@inkedblade.net> wrote:

>On 11/04/2014 03:27 PM, Alan Stearns wrote:
>> On 11/2/14, 11:41 AM, "James Craig" <jcraig@apple.com> wrote:
>>
>>> It's been a couple years since CSS "alt" was proposed. The thread ended
>>> with the implication that it was a necessary and useful idea, and that
>>>it
>>> would be added to Editor's Draft. I was told no further action was
>>> necessary.
>>>
>>>> Start of thread:
>>>> 
>>>>http://lists.w3.org/Archives/Public/www-style/2012Nov/thread.html#msg23

>>>>3
>>>>
>>>> Tab's suggestion of "alt" property:
>>>> http://lists.w3.org/Archives/Public/www-style/2012Nov/0317.html

>>>>
>>>> Clarifications:
>>>> http://lists.w3.org/Archives/Public/www-style/2012Nov/0318.html

>>>
>>> And the property has been shipping in WebKit (as -webkit-alt) for
>>>about a
>>> year now.
>>>
>>>> AX: Implement CSS -webkit-alt property (text alternative for generated
>>>> content pseudo-elements ::before and ::after)
>>>> https://bugs.webkit.org/show_bug.cgi?id=120188

>>>
>>> I'm re-sending this to www-style with the [css-pseudo] prefix because
>>>it
>>> hasn't yet made it into a draft in the last two years.
>>
>> I’ve checked in a rough draft of the property:
>>
>> http://dev.w3.org/csswg/css-pseudo/#alt-property

>
>I object to this change.
>   a) I don't think this is a good solution to the problem.
>   b) If we decide to add it, it belongs in the Content module alongside
>      'content', not in the pseudo-elements module.
>   d) Also, since we're currently tasked with publishing css-pseudo
>without
>      this feature, I don't think the editors should be adding anything
>else
>      without a WG resolution. (Also, in general, while I'm not particular
>      about the order of drafting up text and getting a WG resolution on
>it,
>      I don't think editors should be adding entirely new features without
>      acquiring explicit WG consensus.)

The previous thread seemed favorable, and the discussion last week also
seemed to call for some action. Since you had no objection then I thought
I’d start the ball rolling. I don’t have a strong opinion on what draft
the solution(s) for these use cases reside.

>
>Let me expand on a) since this is the technical, not process, ML...
>
>The first *major* problem with 'alt' is that it cascades poorly. The
>information you're trying to cascade there needs to be tied to the
>information specified for 'content'. Since it's a separate property,
>it will cascade independently, and likely the next style rule with
>'content' will neglect to specify 'alt', leading to a mismatch between
>'alt' and 'content'.

I agree this is a drawback.

>
>The second problem is that we already have solutions to this problem
>that don't require an extra property (that cascades poorly):
>
>Solution A, from CSS3 Generated Content:
>
>   content: url(star.png), "alternate (fallback) text";

In previous threads, this option was discussed but from what I read it was
not favored.

>
>Solution B, from CSS3 Speech:
>
>   @media speech {
>     ... { content: "alternate text"; }
>   }
>
>Solution C, from CSS3 Speech:
>
>   @media not speech {
>     ... { content: "stuff with no speech equivalent"; }
>   }

This does seem to solve the use case of giving AT a hint that the
displayed content should not be read out. What do you think, James?

Thanks,

Alan

Received on Wednesday, 5 November 2014 17:09:23 UTC