Re: headers attribute (was Re: Form elements)

On 2007-05-30 21:24:35 +0200 Patrick H. Lauke <redux@splintered.co.uk> 
wrote:

> What I'm getting at, basically: if HTML 5 wants to do away with 
> versioning, 
> and support current markup, how can it NOT at least define the 
> headers 
> attribute, even if it then marks it as "deprecated" or however this 
> sort of 
> thing will be handled in the future spec? Generally, if there's no 
> versioning, shouldn't *everything* that is in the HTML 4.01 spec also 
> be 
> found in HTML 5? At least all the things currently implemented by 
> UAs? (As 
> much as I'd hate it, this would also include things like 
> width/height/etc 
> attributes on table cells, for instance...not that I want to see 
> these 
> recommended for use, but following the reasoning of 'standardising 
> current 
> browser behaviour', they probably need to be mentioned as well, no?) 
> Trying 
> to understand how deep this concept of unversioned support of all 
> that was 
> and all that will be runs...

The semantics of the HTML elements are in the elements, not in the 
legacy styling attributes from before CSS. Current UAs will not ditch 
support for the legacy attributes over night - and HTML401 still 
exists, but if a browser that does not support them appears, then the 
semantics and future readability is still preserved. And the role that 
those attributes had, have been taken over by CSS.

As for scope and the default auto scope-ing of HTML5, would also play 
much the same role, if a TABLE has headers, but not scope (is it 
possible to use both scope and headers at the same time, btw?). 
Support for headers would not be dropped over night. Som very 
fine-grained connections made with the headers attribute, would be 
lost some places, but most connections would be preserved, (provided 
authors have used TH for header cells) since most tables are pretty 
simple and the auto scope-ing will come into use instead.

When restyling a legacy HTML document with CSS, you _may_ also loos 
some styling, unless you examine every single element. So also, I 
think, with scope. It has a cost and a benefit.

Still, like Ben Boyle, I wonder if headers can be kept, even if scope 
should be promoted. Would headers create any problems for the new 
scope algoritm, for instance? Could headers' role be limited - to thos 
things scope can't handle?
-- 
leif

Received on Thursday, 31 May 2007 23:41:46 UTC