W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: foo {content:title} - a proposal

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 13 Mar 2013 17:50:41 +0100
To: Simon Sapin <simon.sapin@exyr.org>
Cc: James Craig <jcraig@apple.com>, Steve Faulkner <faulkner.steve@gmail.com>, "www-style@w3.org" <www-style@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <20130313175041354131.d1508390@xn--mlform-iua.no>
Hi Simon, thanks for getting the terminology right! HTML5 on @title:

   "If this attribute is omitted from an element, then it implies
    that the title attribute of the nearest ancestor HTML element
    with a title attribute set is also relevant to this element."
    http://www.w3.org/TR/html5/dom.html#the-title-attribute


So one could claim that @title is inherited like @lang.

With regard to GCPM’s named strings, then it sounds a bit complicated. 
For instance because the title keyword in GCPM does not have anything 
to do with the title attribute, as much as I understand. But perhaps 
you could show an example of how it would have worked?

Leif H Silli


Simon Sapin, Wed, 13 Mar 2013 16:56:24 +0100:
> Le 13/03/2013 16:21, Leif Halvard Silli a écrit :
>> Yes. In Webkit. But it isn’t my impression that we are moving towards a
>> situation where*more*  user agents support generated content for void
>> elements. Am I wrong? Opera used to have the best support for generated
>> content on void elements - <input> and <img>. But then they willfully
>> disabled much of what they could do, in order to conform to CSS 2.1 -
>> or what do I know why they did it. And, since I some Opera engineers
>> info gave me that info, they have "disabled" their entire rendering
>> engine. There is no progress in Firefox and IE, that I am aware of.
>> 
>> Thus, the generated content field for void elemnets seems to me like a
>> where the only that is moving, is Webkit. Perhaps one could bring more
>> vendors along with a content:title; ?
> 
> The ::before and ::after pseudo-elements generate CSS boxes *inside* 
> the box generated by the element itself, before/after the first/last 
> child.
> 
> For *replaced* elements like <img> and <input>, everything "inside" 
> is ignored and replaced by something else. Therefore, I think it is 
> consistent with the rest of CSS that ::before and ::after don’t do 
> anything on replaced elements.
> 
> We had a proposal for an ::outside pseudo-element:
> http://www.w3.org/TR/css3-content/#wrapping

> 
> It can be combined as eg. ::outside::after. These would work on 
> replaced elements, but were apparently never implemented and removed 
> from the ED. Anyone knows why it was removed?
> 
> 
> That said, I see another part to this proposal: `content: 
> attr(title)` takes the attribute. But in the given example:
> 
>   <label title="Advisory text.">
>      <input type="text" />
>      <span><::before>Advisory text</::before></span>
>   </label>
> 
> … the title is taken from an ancestor. Does HTML have a concept of 
> title being "inherited" like lang?
> 
> So the second part of the proposal is a "title" keyword to do that. 
> This used case is covered by GCPM’s named strings:
> 
> http://dev.w3.org/csswg/css3-gcpm/#named-strings

> 
> -- 
> Simon Sapin
Received on Wednesday, 13 March 2013 16:51:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT