w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.43k stars 656 forks source link

[css-text] Specify HTML alignment as text-align: -webkit-{left,right,center} #10388

Open emilio opened 3 months ago

emilio commented 3 months ago

All browser engines implement the HTML align attribute with a special value of text-align, rather than as the HTML spec describes. Those values are -{moz,webkit}-{left,right,center}, and for mostly legacy accidents, they are exposed to stylesheets and actively used (yikes).

Rather than keeping the status quo where the specification doesn't contain these values, and the HTML spec says something that no browser does, I propose to define how these works in terms of the -webkit- prefixed version.

Is there any reason not to do that? cc @bfgeek @frivoal

bfgeek commented 3 months ago

Yeah if you are having to ship it then we should spec it, and seems resonable.

Arguably this would go in the align spec, as it is very similar to justify-self:blah for block layout (even though nobody has implemented that yet afaik). https://drafts.csswg.org/css-align-3/#justify-block

Loirooriol commented 3 months ago

IMO this logic makes no sense in text-align because it's not about aligning text.

I think implementations should just implement justify-items and justify-self for blocks, and map:

In fact, the entire point of legacy was supporting these things.

Then, if compat requires supporting text-align: -webkit-{left,right,center}, add that in the compat spec and say that they force justify-items: legacy to gain the corresponding keyword at computed-value time.

Loirooriol commented 3 months ago

CC @fantasai as per https://github.com/whatwg/html/issues/3428

css-meeting-bot commented 1 month ago

The CSS Working Group just discussed [css-text] Specify HTML alignment as text-align: -webkit-{left,right,center}, and agreed to the following:

The full IRC log of that discussion <TabAtkins> emilio: WEbsites try to depend on this -webkit value being exposed
<TabAtkins> emilio: Right now nobody implements the justify-items:legacy stuff
<TabAtkins> emilio: My original idea was to just spec reality here, which is a bit underwhelming
<TabAtkins> emilio: but i'm okay trying to implement justify-items
<TabAtkins> emilio: But we'll probably need to keep the -webkit value for compat
<TabAtkins> emilio: So we should probably choose to spec -webkit-left/right/center either in Alignment or Compat (probably Compat), and let browsers implement Alignment eventually
<TabAtkins> TabAtkins: So your proposal is we spec the -webkit in Compat, and have HTML refer to those, and later see if we can compat-wise fix to Alignment?
<TabAtkins> emilio: Yes. We can possibly have HTML refer to Alignment.
<TabAtkins> TabAtkins: I don't think HTML would take a patch for features that aren't impelmented yet.
<TabAtkins> emilio: Yeah, possibly.
<TabAtkins> astearns: So two steps. First, add -wekbit value to text-align because we have to, not becuase we want to.
<TabAtkins> emilio: yes, because widely depended on
<TabAtkins> astearns: But then a little unclear what the second step is
<TabAtkins> astearns: Oriol talksa bout using justify-items:legacy opting into those values, but I thought the point was sites depending on the values without using justify-items
<TabAtkins> emilio: Right, you have to support the text-align values anyway.
<astearns> ack dbaron
<TabAtkins> emilio: So my pref is to keep them both defined, and then start with having HTML referring to the text-align values, and later switch to justify-items once implemented
<TabAtkins> dbaron: This sounds reasonable to me
<iank_> q+
<TabAtkins> dbaron: Given that everyone does the same thing, and it's not completely clear what the space of changes we can make compatibly *is*, it seems reasonable to spec what we currently have, maybe with a note about what we want to change it to in the future.
<TabAtkins> dbaron: This legacy thing is defined in a way that's supposed to deal with this issue, but it's not clear, for example, how much pages depend on this actually working via text-align
<TabAtkins> dbaron: Because for example you can override this inherited behavior by setting another value on text-align. We need to see if that's something that's ok to break.
<TabAtkins> dbaron: So i'm supportive of moving closer ot reality.
<astearns> ack iank_
<TabAtkins> iank_: dbaron just said what I was gonna
<TabAtkins> astearns: so proposed resolution is: specify the -webkit value for text-align, with a note about what we'd like to do in the future
<TabAtkins> emilio: I think we should specify them without a note, and have HTML take the note about the intended migration
<TabAtkins> dbaron: Sounds fine.
<TabAtkins> TabAtkins: speciy in Text or in Compat?
<TabAtkins> astearns: Compat sounds slightly easier to quarantine
<TabAtkins> emilio: sounds fine, don't mind either way
<TabAtkins> RESOLVED: Specify the -webkit-* values for text-align in the Compat spec.
<TabAtkins> astearns: Who's doing the HTML patch?
<TabAtkins> emilio: I can.
nicoburns commented 1 month ago
dbaron: Because for example you can override this inherited behavior by setting another value on text-align. We need to see if that's something that's ok to break.

My suspicion is that this will turn out not to be something that's ok. The pattern which (with my web author's hat on) I suspect to be common is:

<center>
    <div style="text-align: left">...</div>
</center>