Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

[css-display] Explaining

6 messages.

[css-display] Explaining
"Tab Atkins Jr."   Thu, 12 Jun 2014 16:05:39 -0700

www-style > June 2014 > 0155.html

Received on Thursday, 12 June 2014 23:06:26 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

At the January f2f, we figured out a decent hack that seems to explain the rendering of <br> properly: br { display-box: contents; content: "\a"; white-space: pre; } However, when Hixie was planning to add this to the HTML style sheet, dbaron objected to it on performance reasons: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 So, David, how bad is this? Should we go with a different solution, like a dedicated 'display' value just for <br> (Hixie suggested "display: newline;" in the linked bug). ~TJ
Re: [css-display] Explaining
"Tab Atkins Jr."   Thu, 24 Mar 2016 11:32:55 -0700

www-style > March 2016 > 0367.html

Received on Thursday, 24 March 2016 18:33:42 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

[abracadabra, this thread is NECRO'D!] On Thu, Jun 12, 2014 at 4:05 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > At the January f2f, we figured out a decent hack that seems to explain > the rendering of <br> properly: > > br { > display-box: contents; > content: "\a"; > white-space: pre; > } > > However, when Hixie was planning to add this to the HTML style sheet, > dbaron objected to it on performance reasons: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 > > So, David, how bad is this? Should we go with a different solution, > like a dedicated 'display' value just for <br> (Hixie suggested > "display: newline;" in the linked bug). The HTML spec has had `display: newline` in its CSS section for quite a while. In addition, it's using `display: break-opportunity` to explain the magic of <wbr>. Unless the group decides that the above CSS is actually the best (and can come up with something equivalent for <wbr>), I plan to add "newline" and "break-opportunity" to the Display spec. Any objections? ~TJ
Re: [css-display] Explaining
Brad Kemper   Fri, 25 Mar 2016 10:01:36 -0700

www-style > March 2016 > 0378.html

Received on Friday, 25 March 2016 17:02:15 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

> On Mar 24, 2016, at 11:32 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > [abracadabra, this thread is NECRO'D!] > >> On Thu, Jun 12, 2014 at 4:05 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> At the January f2f, we figured out a decent hack that seems to explain >> the rendering of <br> properly: >> >> br { >> display-box: contents; >> content: "\a"; >> white-space: pre; >> } >> >> However, when Hixie was planning to add this to the HTML style sheet, >> dbaron objected to it on performance reasons: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 >> >> So, David, how bad is this? Should we go with a different solution, >> like a dedicated 'display' value just for <br> (Hixie suggested >> "display: newline;" in the linked bug). > > The HTML spec has had `display: newline` in its CSS section for quite > a while. Wouldn't it be better to just have the 'display-box: contents' version, but let the UA lie about it and optimize it into whatever it needs to, rather than create a whole new display value just for that? Or are we concerned that authors are going to use a duplicate of that UA style sheet rule for other things when they need a line break? They could still do so if they wanted, even if there was a 'newline' value too. > In addition, it's using `display: break-opportunity` to > explain the magic of <wbr>. What is the magic that can't be replicated with text properties? I'm not very familiar with this one. > > Unless the group decides that the above CSS is actually the best (and > can come up with something equivalent for <wbr>), I plan to add > "newline" and "break-opportunity" to the Display spec. Any > objections? > > ~TJ >
Re: [css-display] Explaining
Mats Palmgren   Fri, 25 Mar 2016 19:04:50 +0100

www-style > March 2016 > 0379.html

Received on Friday, 25 March 2016 18:05:26 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: www-style@w3.org.

On 03/25/2016 18:01, Brad Kemper wrote: > Wouldn't it be better to just have the 'display-box: contents' version, > but let the UA lie about it and optimize it into whatever it needs to, > rather than create a whole new display value just for that? Or are we > concerned that authors are going to use a duplicate of that UA style > sheet rule for other things when they need a line break? They could > still do so if they wanted, even if there was a 'newline' value too. +1 Fwiw, this already works in Firefox: <style> nl { display: contents; } nl::before { content: "\a"; white-space: pre; } </style> a<nl></nl>b (we don't support 'content' on arbitrary elements yet, only ::before/::after) /Mats
Re: [css-display] Explaining
fantasai   Tue, 14 Feb 2017 18:51:32 -0500

www-style > February 2017 > 0065.html

Received on Tuesday, 14 February 2017 23:52:08 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: mats@mozilla.com, www-style@w3.org.

On 03/25/2016 02:04 PM, Mats Palmgren wrote: > On 03/25/2016 18:01, Brad Kemper wrote: >> Wouldn't it be better to just have the 'display-box: contents' version, >> but let the UA lie about it and optimize it into whatever it needs to, >> rather than create a whole new display value just for that? Or are we >> concerned that authors are going to use a duplicate of that UA style >> sheet rule for other things when they need a line break? They could >> still do so if they wanted, even if there was a 'newline' value too. > > +1 > > Fwiw, this already works in Firefox: > > <style> > nl { > display: contents; > } > nl::before { > content: "\a"; > white-space: pre; > } > </style> > a<nl></nl>b > > (we don't support 'content' on arbitrary elements yet, > only ::before/::after) The CSSWG resolved to accept this solution, with the caveat that UAs may further restrict the restylability of <br> and <wbr>, essentially reducing it to this set of rules exactly in behavior. Minutes at https://lists.w3.org/Archives/Public/www-style/2017Feb/0062.html Issue tracked at https://github.com/w3c/csswg-drafts/issues/610 ~fantasai
Re: [css-display] Explaining
"Tab Atkins Jr."   Tue, 14 Feb 2017 15:59:56 -0800

www-style > February 2017 > 0066.html

Received on Wednesday, 15 February 2017 00:00:49 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent to: fantasai.lists@inkedblade.net
Copied to: mats@mozilla.com, www-style@w3.org.

On Tue, Feb 14, 2017 at 3:51 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 03/25/2016 02:04 PM, Mats Palmgren wrote: >> >> On 03/25/2016 18:01, Brad Kemper wrote: >>> >>> Wouldn't it be better to just have the 'display-box: contents' version, >>> but let the UA lie about it and optimize it into whatever it needs to, >>> rather than create a whole new display value just for that? Or are we >>> concerned that authors are going to use a duplicate of that UA style >>> sheet rule for other things when they need a line break? They could >>> still do so if they wanted, even if there was a 'newline' value too. >> >> >> +1 >> >> Fwiw, this already works in Firefox: >> >> <style> >> nl { >> display: contents; >> } >> nl::before { >> content: "\a"; >> white-space: pre; >> } >> </style> >> a<nl></nl>b >> >> (we don't support 'content' on arbitrary elements yet, >> only ::before/::after) > > > The CSSWG resolved to accept this solution, with the caveat that > UAs may further restrict the restylability of <br> and <wbr>, > essentially reducing it to this set of rules exactly in behavior. > > Minutes at https://lists.w3.org/Archives/Public/www-style/2017Feb/0062.html > Issue tracked at https://github.com/w3c/csswg-drafts/issues/610 No we didn't; we explicitly resolved that <br> and <wbr> are rendered via magic. We also resolved that that the code example shown here is a reasonable way to reproduce their effects, so it should go in the spec as guidance for authors. But <br> and <wbr> don't respond to these properties at all. (HTML is doing a bit of research to figure out what tiny subset of properties they *do* respond to reliably, and planning to spec that.) ~TJ