Re: what is dt?

Smylers wrote:
> Shelley Powers writes:
>
>   
>> The rejection of the idea, because of how browsers currently implement
>> the DOM for HTML4 puzzles me, since we're changing the DOM for HTML5,
>> anyway.
>>     
>
> Hi Shelley.  Often HTML5 changes don't change the dom -- even brand new
> elements may not involve dom changes, if they happen to be how existing
> browsers behave with unknown elements.
>
> But the issue isn't just with the dom; it's also with how existing
> elements are rendered.
>
>   
>> I am less concerned about issues related to browser companies having
>> to change their code, than I am introducing levels of new confusion
>> with HTML5. This specification should have, as its primary audience,
>> the larger of the groups who are directly impacted by its contents,
>> which would be the web developers/designers.
>>     
>
> The problems with redefining existing behaviour aren't that browser
> developers would need to make changes (they need to make plenty of
> changes for HTML5 anyway!); they are problems for authors.  There are
> two sorts of limitations:
>
> * Not breaking existing pages:  Unfortunately there are existing pages
>   which expect certain behaviour, such as what happens to a <caption>
>   even if it's in a really stupid place in the source.  Changing this
>   behaviour in HTML5 will break how such pages render.  Which will make
>   users avoid HTML5 browsers, cos they break pages.  Which will prevent
>   authors from ever being able to use any of the new HTML5 features.
>   (See also XHTML2.)
>   

If the person set the doctype to HTML5, would they be as equally 
offended by the breakage? Most people I've seen who have been playing 
around with HTML5 have specifically asked what they should be aware of, 
what's changed, what's new. I don't expect anyone to take their existing 
pages, slap on an HTML5 doctype and have an expectation that they may 
not have issues.

Isn't the purpose of DOCTYPE and HTML versioning to prevent such 
problems from happening?

Regardless, I'm not enamored with re-using existing elements for new 
purposes. I'd rather create something new, or use something that doesn't 
require convoluted syntactic and semantic differences being applied to 
elements.

I think that web page author confusion must also be taken into account 
as part of the "breakage" associated with redefining elements such as 
dt/dd, and adding all sorts of non-compatible container rules that 
differ when used within different containers.


>   This is a permanent problem, in that such behaviour can never be
>   changed.
>
> * Being able to create new pages using the HTML5 elements:  Even when
>   HTML5 browsers are released many users will still be on older
>   browsers.  Authors are familiar with the idea of having to support
>   legacy browsers.  So any new HTML5 element or meaning has to have
>   reasonable behaviour in existing browsers, else can't be used until
>   everybody has upgraded.
>
>   Things like default padding on <dd> (in places where an HTML5 browser
>   would not add it) are not particularly a problem, because an author
>   can use CSS to remove unwanted the padding in legacy browsers.
>
>   
I can understand this, and I can understand why this presents a problem 
when using caption and legend. I'm not recommending using either, and 
have specifically been against the use of legend in the past.

But we also have to take into account the probability of introducing 
confusion to web page authors, by redefining the semantics, and the 
syntax, associated with existing elements, just because their use won't 
cause problems with legacy browser. And only because their use won't 
cause legacy problems.

I don't think it is appropriate to use browser legacy as an excuse to 
heap problems on web page authors.

>   In contrast the odd way in which <legend> is currently treated cannot
>   be overridden by authors with CSS or JavaScript.
>
>   This is a temporary problem; HTML5 browsers could start treating
>   <legend> differently, then once all users have upgraded authors can
>   start to use it -- something which is likely to take a decade or so.
>
>   
See above

>> The needs of the browser makers should be secondary.
>>     
>
> Indeed.  The needs of browser makers do not come into this.
>
>   
>> I would rather a new element be defined, clean of past semantics, and
>> used consistently
>>     
>
> Everybody would prefer a well-named element which can be used now.
> Unfortunately that doesn't seem to be possible, so we either have to put
> up with a badly named element or wait a long time to be able to use it.
>
>   

Why is this not possible?

> Obviously different people can legitimately find one of those worse than
> t'other -- this is a judgement call rather than a matter of being
> 'right' or 'wrong', and whatever happens there are clearly going to be
> some people unhappy, who can (legitimately) point to the downside of
> that option.  (We know this because Ian has committed each in turn to
> the spec, and been slated both ways round.)
>   

Thank you for clarifying this for me, I was confused about how decisions 
were being made as to what gets included in the specification.


> Shelley Powers writes:
>
>   
>> Simon Pieters wrote:
>>
>>     
>>> On Thu, 17 Sep 2009 15:02:42 +0200, Shelley Powers
>>> <shelleyp@burningbird.net> wrote:
>>>
>>>       
>>>> Actually, label has been found to be acceptable for use with
>>>> Figure.
>>>>         
>>> I don't think <label> is acceptable, because it interacts with form
>>> controls and is generally allowed anywhere. What if you want a form
>>> control in the figure caption? What if you want a <label> as the
>>> figure content? It wouldn't work if <label> was used as the figure
>>> caption.
>>>
>>> Also, <label> is rendered as an inline element in legacy browsers,
>>> but a figure caption should be block level.
>>>
>>> <dt> does not have these problems.
>>>       
>> Interestingly enough, there's an existing bug about dt/dl because of how
>> they are physically implemented by legacy browsers[1].
>>
>> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7629
>>     
>
> That bug isn't to do with how <dd> is implemented in legacy browsers;
> it's that HTML5's own rendering section needs updating to be in sync
> with recent changes.
>
> Smylers
>
>   

The point is, whatever works for styling for one element, can work for 
another. Discarding label because it's inline is not a valid argument 
against its use.

Shelley

Received on Thursday, 17 September 2009 17:16:24 UTC