24620 2014-02-11 16:08:09 +0000 Needed a rule for user agents about the correct rendering mechanism. If such a mechanism can be changed, this element will be used to finally get rid of in text content. 2014-03-08 01:56:43 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#the-wbr-element P3 normal Unsorted 1 contributor ian anakin_rendine ian master.skywalker.88 mike contributor oldest_to_newest 100298 0 contributor 2014-02-11 16:08:09 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html Multipage: http://www.whatwg.org/C#the-wbr-element Complete: http://www.whatwg.org/c#the-wbr-element Referrer: Comment: Needed a rule for user agents about the correct rendering mechanism. If such a mechanism can be changed, this element will be used to finally get rid of in text content. Posted from: 84.220.197.15 User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 100304 1 anakin_rendine 2014-02-11 18:41:06 +0000 Sorry. The rule is present in the "Rendering" section. A rule which renders the element completely useless, but it is there. 100314 2 ian 2014-02-11 19:45:15 +0000 Is there a remaining issue to be resolved here, or should the bug be closed? 100324 3 anakin_rendine 2014-02-11 20:25:52 +0000 I'm afraid no issue could ever solve the problems of . Are you aware that it's the only tag that never ever receives any {content} value in any of the major browsers?, neither when applied on the element itself, nor when styles are applied on :before and :after pseudo-elements? - Chrome, Opera, Safari (latest editions) do not support {content:'string'} on real elements, and stop rendering them properly when such a property is stated. Anyway they do support {content:url('URL')} both in existing elements (container and empty) and non-existing ones. Moreover, they support pseudo-elements on some rendered elements (I tested it on <img> and )only when their rendering is overridden by a (non-recognized) {content:string} property. - Mozilla Firefox and Internet Explorer simply do not recognize ANY {content} on real elements, so they ignore the statement on real elements and, for inline rendered elements (<img> and ), no content is rendered for :before and :after either. - receives no style and no pseudo-element. It's probably the umpteenth new HTML element whose behavior depends on native browser support. But a zero-width space is not always the best choice for internal word division. 100413 4 ian 2014-02-12 17:28:26 +0000 So... do you want a change to the spec? If so, what, exactly? 100423 5 anakin_rendine 2014-02-12 18:51:11 +0000 I don't think a change can be really achieved. Anyway if it were possible, as text is rendered in pseudo-elements depending on inline elements, it would be useful to define as follows wbr::after { content: '\200B'; } and nothing at all on itself, so that it does not trigger the behavior of <img> and (no pseudo-elements rendered in some browsers). 100637 6 ian 2014-02-14 21:56:23 +0000 Why would wbr::after { content: '\200B'; } ...be better than wbr { content: '\200B'; } ...? I don't follow. 100663 7 master.skywalker.88 2014-02-15 00:43:24 +0000 That content is a string. No user agent, as of now, renders the content of real elements when it is a string (3 out of 5 do it if it is a URL). If it changes, next update of user agents will do it well. Otherwise we'll have to wait a full implementation of {content} in real elements and I think it will take more (seeing what Opera did retiring its support of this feature from v.12 to v.17, or at least I remember so). 101014 8 ian 2014-02-20 20:48:56 +0000 The spec uses CSS features that aren't widely implemented yet to explain things, yes. I'm not sure I follow why this is a problem, though. If you want the browsers to catch up, file a bug with the browsers. :-) 101037 9 anakin_rendine 2014-02-20 21:45:16 +0000 (In reply to Ian 'Hixie' Hickson from comment #8) > The spec uses CSS features that aren't widely implemented yet to explain > things, yes. I'm not sure I follow why this is a problem, though. If you > want the browsers to catch up, file a bug with the browsers. :-) Browsers won't follow the addition of {content} in real element just for this. Anyway, looking to the future, what will happen when this property is defined on container element with a real content? 101038 10 ian 2014-02-20 21:46:21 +0000 I don't understand the question. Are you asking how the 'content' property is intended to work? If so, that's a question for the CSS working group. 101041 11 anakin_rendine 2014-02-20 21:56:08 +0000 (In reply to Ian 'Hixie' Hickson from comment #10) > I don't understand the question. Are you asking how the 'content' property > is intended to work? If so, that's a question for the CSS working group. I'll do it anyway to understand this, because it is important. Here I only wanted to ask you reconsidering default rendering for an element, because now it is not stylable. 101045 12 ian 2014-02-20 22:11:52 +0000 I don't see how changing the default style would affect whether it would be styleable or not. Can you elaborate? 101057 13 anakin_rendine 2014-02-20 22:35:41 +0000 (In reply to Ian 'Hixie' Hickson from comment #12) > I don't see how changing the default style would affect whether it would be > styleable or not. Can you elaborate? As of now, the default for as suggested in the rendering version of the HTML spec cannot be obtained, because it relies on an unsupported feature. But UAs are used to implement it (some of them also do it badly IMO, e.g. Chrome, because it forms a closing tag after it, a thing that it doesn't do with other void elements. But it's just another story). How they implement it is not clear, but I think they do it with internal support mechanisms. And this prevents authors from changing such mechanisms. If a word break occurred as you expect, the word would break because the element is treated like a zero-width space. And if the author changes this to another character (let's say a soft hyphen which would sometimes be preferable in a long-worded language), the element changes as well. This would be the case of wbr{content}, were it supported, but also for wbr::after{content}. But the former isn't supported actually. So the browser parses a , closes the tag if needed and sees it like "some kind of inline element whose purpose is to break long strings of word characters" and prevents any other style to be applied on it, as it does with . It doesn't apply your default, so authors can't modify it. Of course if you change the default it will take a while for browsers to adapt. But it will probably be a shorter time than waiting for them to implement element{content} 101073 14 ian 2014-02-20 23:58:50 +0000 I don't understand why you think it would be a shorter time. Can you elaborate on the basis on which you're determining this? 101079 15 anakin_rendine 2014-02-21 00:35:43 +0000 (In reply to Ian 'Hixie' Hickson from comment #14) > I don't understand why you think it would be a shorter time. Can you > elaborate on the basis on which you're determining this? 2 browsers out of 5 could already do it. If span:after{content:'\00AD';} is applied and then some element are used instead of (empty and placed in breaking points), line breaks appropriately and the hyphen appears. Only Chrome, Opera and Safari should fix a bug (the line breaks if the content is a white space but it doesn't with 0width spaces and hyphens). All they'd have to do is to treat like a in my example. <style> span:after{content:'\00AD';} </style> breakingbreakingbreakingbreakingbreakingbreakingbreaking 101125 16 ian 2014-02-21 17:47:30 +0000 I don't understand why browsers implementing ::after and U+00AD line breaking means that browsers are at all likely to change their implementations before 'content' is implemented. 101127 17 anakin_rendine 2014-02-21 17:59:17 +0000 (In reply to Ian 'Hixie' Hickson from comment #16) > I don't understand why browsers implementing ::after and U+00AD line > breaking means that browsers are at all likely to change their > implementations before 'content' is implemented. Because seems to be meant to solve the problem of word-breaking through the use of the rendering layer (i.e. it does what it does because CSS associates it with pseudo-content and this breaks words). If they implement this concept in a way every browser is able to do as of now, they'll achieve the very same objective (inserting a zero-width space via CSS and allowing authors to change this character to one more suitable if needed). I think that modifying UA stylesheet for next versions is easier than implementing element{content} AND modifying UA stylesheet. I mean, they already have the technology and it only has to be exploited. Half the work is done. It's a matter of logic, I think. 101136 18 ian 2014-02-21 19:14:55 +0000 The problem with that is that it means the browser vendors wasting time changing one thing that they know they'll change again later. That's churn. It's better for the spec to say where they should be aiming on the long term. Having said that, if you want to get the browser vendors to take baby steps towards this, it is worth filing bugs with them saying that while they don't have 'content' implemented on elements, they should instead implement this using a pseudo-element. 101138 19 anakin_rendine 2014-02-21 19:30:33 +0000 (In reply to Ian 'Hixie' Hickson from comment #18) > The problem with that is that it means the browser vendors wasting time > changing one thing that they know they'll change again later. That's churn. > It's better for the spec to say where they should be aiming on the long term. > > Having said that, if you want to get the browser vendors to take baby steps > towards this, it is worth filing bugs with them saying that while they don't > have 'content' implemented on elements, they should instead implement this > using a pseudo-element. The theoretical part of me feels that you're right. The technical part of me says that it would have wonderful to use now and correctly (I have an old question with and content, never mind). Anyway the solution you have proposed is a good compromise, or lest it would be if I were that "important" to suggest such things to vendors. Thank you nonetheless. 102098 20 ian 2014-03-08 00:52:19 +0000 For what it's worth, I don't think you'd have any less luck than I would convincing them to implement that. :-) The problem wouldn't be that the person is unimportant, more that the arguments for the feature aren't compelling enough... 102102 21 master.skywalker.88 2014-03-08 01:56:43 +0000 Big issues don't get fixed because they're too big and difficult. Small issues don't get fixed either because they're too small and unimportant. Anyway I'll find a way how to convince them supporting a workaround, or maybe other ways will come for this. I just noticed that using in prose, as using any other character-level separation, gives problems in 2 important cases: - when copying text from a web source containing character separators, often zero-width spaces appear as "unrecognizable characters" (question marks or empty blocks), while soft hyphens are translated into simple hyphens - search engines index badly pages whose text contains character-level exotic separators. resolves these issues because the separator is markup-level. Someone should use these arguments with them. Wider support -> wider use -> better results in search engines and data mining.