W3C home > Mailing lists > Public > www-style@w3.org > November 2014

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

From: James Craig <jcraig@apple.com>
Date: Wed, 05 Nov 2014 09:31:45 -0800
Cc: Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>, "jackalmage@gmail.com" <jackalmage@gmail.com>, fantasai <fantasai@inkedblade.net>
Message-id: <C6212355-531F-4787-8C7A-FEFE8D94A8DC@apple.com>
To: fantasai <fantasai.lists@inkedblade.net>
Please see the 2012 www-style thread referenced below. 
>>>> http://lists.w3.org/Archives/Public/www-style/2012Nov/thread.html#msg233

I originally discussed non url() content fallback and was persuaded by members of the CSS WG that “alt” was the best solution. Among other reasons, the content property provides no way to specify fallback content for rendered *text* content such as glyphs.

content: "\2730", attr(title); /* pointless */

Speech media is mutually exclusive with screen media, so it *only* covers the DAISY case (linearized audio) and does not apply to any assistive technology as far as I can tell. Perhaps the speech media type should be renamed linearized-audio to avoid to misconception that it applies to *screen* readers and other assistive technology that use speech, including screen magnifiers.

The reader media type (also referenced in the original thread) has the same media type exclusivity problem and to my knowledge has been abandoned.

I do not have a preference if alt lives in the PSEUDO or CONTENT module; but I heard PSEUDO suggested at the Working Group meeting on Friday morning. Perhaps these two CSS modules should be combined to avoid this confusion in the future?

> On Nov 5, 2014, at 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#msg233
>>>> 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.)
> 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'.
> 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";
> Solution B, from CSS3 Speech:
>  @media speech {
>    ... { content: "alternate text"; }
>  }
> Solution C, from CSS3 Speech:
>  @media not speech {
>    ... { content: "stuff with no speech equivalent"; }
>  }
> Why are we not pursuing deployment of these, instead of copying a
> poorly-designed WebKit idea?
> ~fantasai

Received on Wednesday, 5 November 2014 17:32:22 UTC

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