This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Annie pointed out that if an entire table cell (as opposed to just the text in it) is selected when the user sets the background color, the user expects the whole cell's background to be set instead of just the text in it.
How would we define the case where "the entire table gets selected"? Do we mean when a td node falls inside the range of a selection?
Well, selecting stuff changes the background color of whatever you select. With table cells, sometimes browsers will change the background color of the whole cell, sometimes the background color of just the text. Whatever happens, we want the hiliteColor/backColor commands to set the background of whatever has its background color changed by the selection. This means we want UI requirements, I think. I'll have to look at how browsers behave here.
IE9: Acts like the current spec. Only <font>s are added, never adds a background to the table cell itself. Firefox 9.0a2: Several behaviors. hiliteColor in CSS mode adds the style attribute to any table cells that are fully included in the selection, not creating wrappers, as is its behavior with any block elements. But if the contents are only partially selected, it creates a wrapper. backColor in CSS mode sets the background on any table cell that contains part of the selection regardless of whether its contents are fully contained. backColor in non-CSS mode seems to set the background on the first table cell that contains part of the selection regardless of whether its contents are fully contained, but not any other table cells. Chrome 16 dev: For both backColor and hiliteColor, acts like the current spec. Only <span>s/<font>s are added, never adds a background to the table cell itself. Opera Next 11.50: For hiliteColor, acts more or less like the current spec. For backColor, seems to add the attribute only to the table cell, similar to Firefox. So I'm not sure how to go about this. Firefox and Opera both support some way of adding backgrounds to table cells themselves, which the current spec doesn't. Maybe we should appropriate backColor to give background colors to table cells and/or the editing host, instead of making it a clone of hiliteColor? This would be somewhat like how Gecko behaves in non-CSS mode. We could go up to the nearest ancestor of each affected node that's either a td or th or editing host, and set a background on that. But it's awfully confusing that it works sometimes for table cells and sometimes for the editing host. Also, we don't want to add attributes to the editing host. At this point my thinking is that we should leave backColor/hiliteColor as they are, and define a new tableCellBackground command or something if we want this feature. Does anyone else have opinions?
I would be fine with keeping what the current spec specifies and adding a new command for table cells. I also wonder if we should specify that tr elements (and other similar elements) would ever get a background color attribute or not, because the situation might be tricky if you run the command with all but one cell in a row selected, and then extending the selection to include that row as well and rerunning the command...