UA style for <br> and <wbr>

[zcorpan]

See
w3c/csswg-drafts#610 (comment)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26264#c6
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28080#c3

[domenic]

This should be a relatively simple spec fix, right?

I guess nobody is going to pass the tests since nobody implements these in CSS from what I understand... not sure what we should do there. Do UAs plan to do so? Maybe we should just give up and stop trying to define these through CSS?

[zcorpan]

all: unset is implemented in WebKit/Chromium/Gecko:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4831

display: contents is ... implemented in WebKit/Chromium/Gecko, but with this simple test case there are 3 different behaviors (I think Gecko is per spec):

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4832

I did not test Edge.

Anyway, yeah the spec fix itself should be simple. Slightly more work is probably testing + browser bugs and getting implementors interested in passing the tests...

[domenic]

In particular the test cases that get the computed (used?) style of br/wbr are the ones I'm worried no engine will ever be interested in passing.

[zcorpan]

Hmmm. It's unclear to me if the discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25503 applies equally to the proposed change now. @dbaron?

Also I'll note that content: "foo" doesn't work in most (all?) browsers except for ::before/::after.

[annevk]

@domenic they pass similar tests for other rules in the user agent stylesheet. Is there a performance concern here? If so, then we should bring that feedback back to the CSS WG, though it would be a little weird for them to recommend something like that then since they have implementers involved too.

[domenic]

It's more that everyone already has a br implementation that I assume they're happy with. There is a performance concern, which the CSSWG addressed by suggesting the !important reset. That allows implementers to work around the performance issue by having some sort of fast path that uses their existing br logic but reports "fake" used styles. My skepticism is that any implementer would want to implement such a fast path solely for the purpose of passing such tests; it doesn't really have any author or user facing benefit.

Stated another way: it's great that we've shown CSS has a way to express br. But actually mandating that the observable world act as if br was rendered via CSS isn't so useful, I imagine.

Of course this is all speculation. Maybe there were implementers in the room who were already adding this fast path/used style reporting issue to their Q2 goals.

[dbaron]

I don't think w3c/csswg-drafts#610 (comment) is an accurate reflection of the WG's discussion (in which I did raise performance concerns), which concluded with:

RESOLVED: keep <br> and <wbr> magic, but add an explainer about how to mimic the results

I was arguing for something similar to what Domenic just wrote as I was typing this, and I think the CSS WG agreed.

[dbaron]

Maybe that's not quite accurate, now that I'm remembering the discussion. The idea is that implementations still would have native implementations, but the spec would be defining the expected behavior of those native implementations as equivalent to the given CSS, which (given the all: reset ! important) allows very little styling/customization. The question is if that CSS actually Web-compatibly agrees with what the native <br> implementations do, down to the level of ignoring all CSS properties (including, say, font-size and line-height).

[dbaron]

One further note: given that I think the intent is that implementations have non-CSS <br> implementations, I think the spec should (non-normatively) say that that's the intent, so that readers of the spec understand what was intended.

[rniwa]

Yeah, it's not really helpful to make these elements be defined in terms of UA stylesheet if that's not what we're trying to achieve. It's rather misleading especially if we haven't figured out the compatibility implications.

[domenic]

I've posted #2298 as an attempt to concretize this discussion. Given the disappointing lack of interop for the test case at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4837 , we might not be able to come up with something perfect, but at least what's in that PR seems like a start toward something a bit more aligned with implementations than the fictional display types the spec currently uses.