Re: [csswg-drafts] Review HTML fieldset/legend spec

@MatsPalmgren 

> FYI, Gecko supports grid/flex/column layout of the <fieldset> contents by propagating those values to the inner anonymous box. I agree that display:fieldset + exposing the inner box with a pseudo for direct styling is probably cleaner but I wonder how web-compatible that would be at this point.

I think we'd want fieldsetness (i.e. manipulating the first legend into the border area) to be something independent of the inner display type, so something like the 'list-item' keyword, which can be combined with various inner/outer display types. So you would say `display: block grid fieldsetty`.

The Web-compat issue is interesting. I definitely don't like using `appearance` as a general switch for this, to turn it on for arbitrary elements. It's got significant layout implications, no visual implications, and isn't really a good fit for `appearance`; also I do imagine that authors will want to use this ability on other elements, if it becomes accessible through a property, so we should design the trigger for it as if we were designing a new feature for general use. 

If we need `display: <inner-display>` to work on `<fieldset>` without overwriting the fieldsetness, then we can run the following computation: if the element is `<fieldset>` and the `appearance` is not `none` (or is `auto` or is not `none`/`button`/whatever), then the computed value of `display` includes `fieldsetty` (or whatever we choose to call it). That should deal with the Web-compat issue, and also make `appearance: none` turn off FIELDSET's specialness, which is nice because `appearance: none` is supposed to take away the specialness of all other form controls.

> display:legend would have the same problem as for fieldset - how do you specify grid/flex layout of its contents?

`display: legend grid`. I did say it should be an outer display type, that implies you can combine it with an inner one like `grid` or `flex`. :)

> > “The 'display' property is expected to behave as if its computed value was blockified. This does not change the computed value.” Why does the legend not change its computed value?
>
> Determining which box is the rendered legend happens during box construction, so it seemed "too late" to change the computed value at that point. (I could be wrong.)

Is it a Web-compat requirement that legends which are not the “rendered legend” be inline-level? Because if not, then the `legend` property (or as I'm proposing it, `display: legend`) can just blockify unconditionally.

> Agreed, this is whatwg/html#4013. &hellip; see whatwg/html#3929.

Thanks, I'll follow up there.

@zcorpan 

> I agree that it would be nice to unprefix (#3024), but since the current spec for appearance isn't web-compatible, Mozilla are reverse engineering Chrome and ignoring the spec (#1250). Also, web compat requires more values to be supported than that.

If the current spec isn't Web-compatible, then it needs to be fixed.  It seems like there needs to be some discussion among interested properties in how exactly `appearance` should be specced (and the CSSWG is proposing we all do that during TPAC next month), but the HTML spec should not be relying on -webkit-appearance to define a new feature.

> Unfortunately, that is not web compatible. Web pages set 'display' to something and expect the fieldset magic to still be there.

See response to Mats, above.

> I'm happy to have it be moved elsewhere when it has stabilized.

Cool.

>> If the legend is overlaying the corner of the box, it should also obscure that part of the adjacent border. It seems perfectly reasonable for an author to want to position the legend over the corner: having only the block-start side of the border disappear in that case looks ugly. Mask the affected part of the border, nevermind which side it is.
> 
> I think this wouldn't match how it's implemented.

I think that's incorrect, since Firefox masks the inline-start/end edges just fine: [testcase](http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cfieldset%3E%3Clegend%20style%3D%22margin-left%3A%20-1em%3B%22%3E...%3C%2Flegend%3E%3C%2Ffieldset%3E)

> "Expected" is a normative keyword in the rendering section:

OK, sure, but your spec is written such that this section is defining the behavior of certain CSS keywords and properties. That behavior should to be *required*, not optional, because we don't want to create new CSS keywords and properties whose behavior is “optional”. Use the “expected to” conditions on whether or not FIELDSET and LEGEND are mapped to these new display types you're creating, but don't use it when defining how the new display types are defined.

> “The following properties are expected to inherit from the 'fieldset'” ... we should try to find some better to make sure this list stays up-to-date. :/
>
> Any suggestion? :)

Yeah, I'm pretty convinced at this point that the postscript is a better way to go. :) A lot of the exceptional layout rules you're adding here would just go away.

> > p.s. Currently pondering the last two points, and wondering if it would work better to define this as the legend being taken out-of-flow from the fieldset's contents, laid out over the fieldset's border, and accounted for as an increase in the fieldset's border/padding area. That would probably address a lot of the sizing considerations better, and in a way that won't break as CSS evolves.
>
> Maybe. I'd like to spec it in a way that closely follows how it's implemented, though.

Looking at all the exceptions you're creating, I think it's creating more of a mess to do it this way at the spec level, though. It's not just the exceptions you've listed, it's also that the model I'm proposing will behave as expected in cases we haven't thought of and in cases that don't exist yet, whereas the two-box model that you're proposing will keep needing explicit exceptions to divide one box’s behavior across two boxes. Its just not going to be as maintainable.

(There's a number of cases where the spec has one box whereas e.g. Gecko generates two nested boxes. E.g. scroll containers and table cells, IIRC. It doesn't mean those cases should use nested boxes in the spec.)

@frivoal 

> I don't question the need to be able to turn this off, nor the need for interop when it is on. However that does not necessarily require the introduction of the ability to turn the magic on on arbitrary markup. It seems to me that the type of layout that it offers is very close to the sort of layout that can be achieved with grid.

I don't think this is true. The way the legend takes up space outside the fieldset border, for example, can't be duplicated with grid afaict...

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3094#issuecomment-420725305 using your GitHub account

Received on Wednesday, 12 September 2018 17:08:49 UTC